Você está na página 1de 402

Um Guia para o

CONHECIMENTO EM SCRUM

(GUIA SBOK )
3rd Edio
Inclui dois captulos sobre Escalar
Scrum em Grandes Projetos e na Empresa

Um Guia Completo para Entregar Projetos Utilizando o Scrum


Um Guia para o

CONHECIMENTO EM SCRUM
(Guia SBOK)
3rd Edio

Um Guia Completo para Entregar Projetos Utilizando o Scrum


2017 SCRUMstudy, uma marca da VMEdu, Inc. Todos os direitos reservados.

Library of Congress Cataloging-in-Publication Data

Um Guia para o Conhecimento em Scrum (Guia SBOK) Edio 3rd


Ttulo original: A Guide to the SCRUM BODY OF KNOWLEDGE (SBOKGUIDE) 3rd Edition

Inclui referncias bibliogrficas e ndice.


ISBN: 978-0-9899252-0-4

1. Modelo Scrum. I. SCRUMstudy. II. Guia SBOK

2013950625

ISBN: 978-0-9899252-0-4

Publicado por:
SCRUMstudy, uma marca da VMEdu, Inc.
12725 W. Indian School Road, Suite F-112
Avondale, Arizona 85392 USA
Email: sbok@scrumstudy.com
Website: www.scrumstudy.com

SBOK, o logotipo SCRUMstudy, SDC, SMC, SAMC, SPOC, e ESM so marcas comerciais da SCRUMstudy
(uma marca da VMEdu, Inc.) Para obter uma lista completa das marcas da SCRUMstudy, entre em contato com o
Departamento Jurdico da SCRUMstudy.

Um Guia para o Conhecimento em Scrum (Guia SBOK) fornecido para fins educacionais. SCRUMstudy ou VMEdu,
Inc. no garantem que este guia seja adequado para qualquer outra finalidade, no fazem nenhuma garantia expressa ou
implcita de qualquer tipo e no assume nenhuma responsabilidade por erros e omisses. No se assume responsabilidade
por danos acidentais ou consequentes relacionados com ou decorrente do uso das informaes aqui contidas.

SCRUMstudy agradece correes e comentrios sobre seus livros. Por favor, fique vontade para enviar comentrios
sobre erros tipogrficos, de formatao ou outros. Voc pode fazer uma cpia da pgina relevante do livro, marque o erro e
envie para o endereo acima ou por e-mail: sbok@scrumstudy.com.

Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma ou por qualquer meio, eletrnico,
manual, fotocpia, gravao ou por qualquer sistema de armazenagem e recuperao, sem autorizao prvia por escrito
da editora.

10 9 8 7 6 5 4 3 2
PRLOGO
A Guide to the Scrum Body of Knowledge (SBOK Guide) provides guidelines for the successful
implementation of Scrumthe most popular Agile product development and project delivery approach.
Scrum, as defined in the SBOK Guide, is a framework which is applicable to portfolios, programs, or
projects of any size or complexity; and may be applied effectively in any industry to create a product,
service, or other result.

The SBOK Guide is intended for use as a reference and knowledge guide by both experienced Scrum and
other product or service development practitioners, as well as by persons with no prior experience or
knowledge of Scrum or any other project delivery method. This new edition of the SBOK Guide provides
additional insight into Scrum best practices, particularly in the areas of scaling Scrum. Two chapters have
been added to the SBOK Guide to specifically address scaling Scrum for large projects (Chapter 13), and
scaling Scrum for the Enterprise (Chapter 14). As the popularity and application of the Scrum framework
grows and evolves globally, our goal is to share the lessons learned and best practices as part of the
SBOK Guide.

The SBOK Guide draws from the combined knowledge and insight gained from thousands of projects
across a variety of organizations and industries. This Third Edition adds to the collective contributions of
experts in Scrum and project delivery. In particular, feedback from the global Scrum community played a
large role in identifying improvements and additions to the SBOK Guide. Its development has truly been a
collaborative effort from a large number of experts and practitioners in a variety of disciplines.

Wide adoption of the SBOK Guide framework standardizes how Scrum is applied to projects across
organizations globally, as well as significantly helps to improve their Return on Investment. Additionally, it
promotes greater thought and deliberation regarding the application of Scrum to many types of projects,
which will in turn contribute towards expanding and enriching the body of knowledge and consequently
future updates to this guide.

Although the SBOK Guide is a comprehensive guide and framework for delivering projects using Scrum,
its contents are organized for easy reference, regardless of the readers prior knowledge on the subject. I
hope each reader will learn from and enjoy it as much as the many authors and reviewers learned from and
enjoyed the process of collating the collective knowledge and wisdom contained within it.

Tridibesh Satpathy,

Autor Principal, Guia SBOK


NDICE

NDICE
1. INTRODUO ........................................................................................................................................ 1
1.1 Viso geral do Scrum...................................................................................................................... 2
1.1.1 Breve Histria do Scrum ............................................................................................ 3
1.2 Por que usar o Scrum? ................................................................................................................... 4
1.2.1 Escalabilidade de Scrum ............................................................................................ 5
1.3 Objetivo do Guia SBOK ............................................................................................................... 6
1.4 Estrutura do Guia SBOK ............................................................................................................. 7
1.4.1 Como Utilizar o Guia SBOK? ................................................................................... 8
1.4.2 Princpios do Scrum ................................................................................................... 9
1.4.3 Aspectos do Scrum .................................................................................................. 11
1.4.4 Processos do Scrum ................................................................................................. 16
1.5 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................... 20
2. PRINCPIOS ......................................................................................................................................... 21
2.1 Introduo ..................................................................................................................................... 21
2.2 Guia de Papis ............................................................................................................................. 22
2.3 Controle de Processos Empricos ................................................................................................. 22
2.3.1 Transparncia .......................................................................................................... 22
2.3.2 Inspeo................................................................................................................... 24
2.3.3 Adaptao ................................................................................................................ 24
2.4 Auto-organizao .......................................................................................................................... 27
2.4.1 Benefcios da Auto-organizao .............................................................................. 27
2.5 Colaborao.................................................................................................................................. 29
2.5.1 Benefcios da Colaborao em Projetos Scrum ....................................................... 29
2.5.2 Importncia da Colocation em Colaborao ........................................................... 31
2.6 Priorizao baseada em valor....................................................................................................... 31
2.7 Time-boxing .................................................................................................................................. 33
2.7.1 Scrum Time-boxes ................................................................................................... 33
2.8 Desenvolvimento iterativo ............................................................................................................. 36
2.9 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................... 38

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) I


NDICE

3. ORGANIZAO .................................................................................................................................... 39
3.1 Introduo ..................................................................................................................................... 39
3.2 Guia de Papis ............................................................................................................................. 40
3.3 Papis do Projeto Scrum .............................................................................................................. 40
3.3.1 Papis Centrais ........................................................................................................ 41
3.3.2 Papis No-Essenciais.............................................................................................. 42
3.4 Dono do Produto ........................................................................................................................... 43
3.4.1 Voz do Cliente (VOC) ............................................................................................... 45
3.4.2 Dono do Produto Chefe ........................................................................................... 45
3.5 Scrum Master................................................................................................................................ 45
3.5.1 Scrum Master Chefe ................................................................................................ 47
3.6 Time Scrum................................................................................................................................... 47
3.6.1 Seleo de Pessoal................................................................................................... 49
3.6.2 Tamanho do Time Scrum......................................................................................... 49
3.7 Scrum em Projetos, Programas e Portflios ................................................................................. 50
3.7.1 Definio de Projeto, Programa e Portflio ............................................................ 50
3.7.2 Scrum em Projetos .................................................................................................. 51
3.7.3 Scrum em Portflios e Programas ........................................................................... 53
3.7.4 Mantendo o envolvimento do Stakeholder ............................................................ 55
3.8 Resumo das Responsabilidades................................................................................................... 56
3.9 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................... 57
3.10 Teorias Populares de RH e suas Relevncias para o Scrum ....................................................... 58
3.10.1 O Modelo de Tuckman de Dinmica de Grupo ....................................................... 58
3.10.2 Gerenciamento de Conflitos.................................................................................... 59
3.10.3 Tcnicas de Gerenciamento de Conflitos ................................................................ 59
3.10.4 Estilos de Liderana ................................................................................................. 61
3.10.5 Teoria de Maslow sobre a Hierarquia de Necessidades ......................................... 63
3.10.6 Teoria X e Teoria Y ................................................................................................... 64
4. JUSTIFICATIVA DE NEGCIO ............................................................................................................ 65
4.1 Introduo ..................................................................................................................................... 65
4.2 Guia de Papis ............................................................................................................................. 66

II 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


NDICE

4.3 Entrega Orientada a Valor ............................................................................................................ 66


4.3.1 Responsabilidades do Dono do Produto na Justificativa de Negcio ..................... 68
4.3.2 Responsabilidades de outros Papis do Scrum na Justificativa de Negcios ......... 68
4.4 Importncia da Justificativa de Negcio ........................................................................................ 69
4.4.1 Os Fatores usados para Determinar a Justificativa de Negcio .............................. 69
4.4.2 Justificativa de Negcio e o Ciclo de Vida do Projeto ............................................. 70
4.5 Tcnicas da Justificativa de Negcio ............................................................................................ 72
4.5.1 Estimativa do Valor do Projeto ................................................................................ 72
4.5.2 Planejamento para o Valor ...................................................................................... 74
4.5.3 Ranking Relativo de Priorizao .............................................................................. 76
4.5.4 Mapa da Estria ....................................................................................................... 76
4.6 Justificativa de Valor Contnuo...................................................................................................... 76
4.6.1 Anlise de Valor Agregado ...................................................................................... 77
4.6.2 Diagrama de Fluxo Cumulativo (DFC) ...................................................................... 79
4.7 Confirmar a Realizao de Benefcios .......................................................................................... 80
4.7.1 Prottipos, Simulaes e Demonstraes ............................................................... 80
4.8 Resumo das Responsabilidades................................................................................................... 81
4.9 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................... 82
5. QUALIDADE ......................................................................................................................................... 83
5.1 Introduo ..................................................................................................................................... 83
5.2 Guia dos Papis............................................................................................................................ 84
5.3 Definio de Qualidade................................................................................................................. 84
5.3.1 Qualidade e Escopo ................................................................................................. 85
5.3.2 Qualidade e Valor de Negcio ................................................................................. 85
5.4 Critrios de Aceitao e Backlog Priorizado do Produto ............................................................... 86
5.4.1 Escrevendo os Critrios de Aceitao ..................................................................... 88
5.4.2 Os Critrios Mnimos de Aceitao ......................................................................... 88
5.4.3 Definio de Pronto ............................................................................................. 89
5.4.4 Aceitao ou Rejeio dos Itens do Backlog Priorizado do Produto ....................... 90
5.5 Gerenciamento de Qualidade em Scrum ...................................................................................... 90
5.5.1 Planejamento de Qualidade .................................................................................... 91

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) III


NDICE

5.5.2 Controle de Qualidade e Garantia de Qualidade .................................................... 92


5.5.3 O Ciclo PDCA Planejar-Fazer-Verificar-Agir (Plan-Do-Check-Act)............................ 93
5.6 Resumo das Responsabilidades................................................................................................... 94
5.7 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................... 95
6. MUDANA ............................................................................................................................................ 97
6.1 Introduo ..................................................................................................................................... 97
6.2 Guia dos Papis............................................................................................................................ 98
6.3 Viso geral .................................................................................................................................... 98
6.3.1 As Solicitaes de Mudanas Aprovadas e No-Aprovadas .................................... 99
6.4 Mudana em Scrum .................................................................................................................... 101
6.4.1 O Equilbrio entre a Flexibilidade e a Estabilidade ................................................ 101
6.4.2 Conquistando a Flexibilidade ................................................................................ 101
6.5 Integrao de Mudanas ............................................................................................................ 107
6.5.1 As Mudanas em um Sprint................................................................................... 107
6.6 Mudana em Portflios e Programas .......................................................................................... 113
6.6.1 Em Portflio ........................................................................................................... 113
6.6.2 Em Programa ......................................................................................................... 113
6.7 Resumo das Responsabilidades................................................................................................. 115
6.8 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................. 116
7. RISCO ................................................................................................................................................. 117
7.1 Introduo ................................................................................................................................... 117
7.2 Guia dos Papis.......................................................................................................................... 118
7.3 O que Risco? ........................................................................................................................... 118
7.3.1 Diferena entre Riscos e Problemas ...................................................................... 118
7.3.2 Atitude de Riscos ................................................................................................... 119
7.4 Procedimento no Gerenciamento de Riscos ............................................................................... 120
7.4.1 Identificao de Riscos .......................................................................................... 120
7.4.2 Avaliao de Riscos ................................................................................................ 121
7.4.3 Priorizao de Riscos ............................................................................................. 125
7.4.4 Mitigao de Riscos ............................................................................................... 126
7.4.5 Comunicao de Riscos ......................................................................................... 127

IV 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


NDICE

7.5 Minimizao de Riscos Atravs do Scrum .................................................................................. 128


7.6 Riscos em Portflios e Programas .............................................................................................. 129
7.6.1 Em Portflio ........................................................................................................... 129
7.6.2 Em Programa ......................................................................................................... 130
7.7 Resumo das Responsabilidades................................................................................................. 131
7.8 Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................. 132
8. INICIAR ............................................................................................................................................... 133
8.1 Criar a Viso do Projeto .............................................................................................................. 137
8.1.1 Entradas ................................................................................................................. 139
8.1.2 Ferramentas .......................................................................................................... 142
8.1.3 Sadas ..................................................................................................................... 143
8.2 Identificar o Scrum Master e o(s) Stakeholder(s) ........................................................................ 145
8.2.1 Entradas ................................................................................................................. 147
8.2.2 Ferramentas .......................................................................................................... 149
8.2.3 Sadas ..................................................................................................................... 151
8.3 Formar o Time Scrum ................................................................................................................. 152
8.3.1 Entradas ................................................................................................................. 154
8.3.2 Ferramentas .......................................................................................................... 155
8.3.3 Sadas ..................................................................................................................... 156
8.4 Desenvolver o(s) pico(s) ........................................................................................................... 158
8.4.1 Entradas ................................................................................................................. 160
8.4.2 Ferramentas .......................................................................................................... 163
8.4.3 Sadas ..................................................................................................................... 165
8.5 Criar o Backlog Priorizado do Produto ........................................................................................ 167
8.5.1 Entradas ................................................................................................................. 169
8.5.2 Ferramentas .......................................................................................................... 170
8.5.3 Sadas ..................................................................................................................... 172
8.6 Conduzir o Planejamento da Release......................................................................................... 174
8.6.1 Entradas ................................................................................................................. 176
8.6.2 Ferramentas .......................................................................................................... 177
8.6.3 Sadas ..................................................................................................................... 178

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) V


NDICE

8.7 Fase do Diagrama de Fluxo de Dados ....................................................................................... 180


9. PLANEJAR E ESTIMAR ..................................................................................................................... 181
9.1 Criar a Estria de Usurio ........................................................................................................... 185
9.1.1 Entradas ................................................................................................................. 187
9.1.2 Ferramentas .......................................................................................................... 188
9.1.3 Sadas ..................................................................................................................... 190
9.2 Aprovar, Estimar e Comprometer as Estrias de Usurio .......................................................... 192
9.2.1 Entradas ................................................................................................................. 193
9.2.2 Ferramentas .......................................................................................................... 193
9.2.3 Sadas ..................................................................................................................... 197
9.3 Criar as Tarefas .......................................................................................................................... 198
9.3.1 Entradas ................................................................................................................. 199
9.3.2 Ferramentas .......................................................................................................... 199
9.3.3 Sadas ..................................................................................................................... 201
9.4 Estimar as Tarefas ...................................................................................................................... 203
9.4.1 Entradas ................................................................................................................. 204
9.4.2 Ferramentas .......................................................................................................... 205
9.4.3 Sadas ..................................................................................................................... 206
9.5 Criar o Backlog do Sprint ............................................................................................................ 207
9.5.1 Entradas ................................................................................................................. 209
9.5.2 Ferramentas .......................................................................................................... 210
9.5.3 Sadas ..................................................................................................................... 211
9.6 Fase do Diagrama de Fluxo de Dados ....................................................................................... 212
10. IMPLEMENTAR .............................................................................................................................. 213
10.1 Criar os Entregveis ................................................................................................................... 217
10.1.1 Entradas ................................................................................................................. 219
10.1.2 Ferramentas .......................................................................................................... 221
10.1.3 Sadas ..................................................................................................................... 222
10.2 Conduzir a Reunio Diria .......................................................................................................... 224
10.2.1 Entradas ................................................................................................................. 226
10.2.2 Ferramentas .......................................................................................................... 227

VI 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


NDICE

10.2.3 Sadas ..................................................................................................................... 228


10.3 Refinamento do Backlog Priorizado do Produto ......................................................................... 230
10.3.1 Entradas ................................................................................................................. 232
10.3.2 Ferramentas .......................................................................................................... 234
10.3.3 Sadas ..................................................................................................................... 235
10.4 Fase do Diagrama de Fluxo de Dados ....................................................................................... 236
11. REVISO E RETROSPECTIVA...................................................................................................... 237
11.1 Convocar o Scrum de Scrums .................................................................................................... 241
11.1.1 Entradas ................................................................................................................. 242
11.1.2 Ferramentas .......................................................................................................... 243
11.1.3 Sadas ..................................................................................................................... 244
11.2 Demonstrar e Validar o Sprint ..................................................................................................... 246
11.2.1 Entradas ................................................................................................................. 248
11.2.2 Ferramentas .......................................................................................................... 249
11.2.3 Sadas ..................................................................................................................... 250
11.3 Retrospectiva do Sprint............................................................................................................... 251
11.3.1 Entradas ................................................................................................................. 253
11.3.2 Ferramentas .......................................................................................................... 253
11.3.3 Sadas ..................................................................................................................... 255
11.4 Fase do Diagrama de Fluxo de Dados ....................................................................................... 257
12. RELEASE ....................................................................................................................................... 259
12.1 Envio de Entregveis .................................................................................................................. 262
12.1.1 Entradas ................................................................................................................. 263
12.1.2 Ferramentas .......................................................................................................... 264
12.1.3 Sadas ..................................................................................................................... 265
12.2 Retrospectiva do Projeto ............................................................................................................. 266
12.2.1 Entradas ................................................................................................................. 267
12.2.2 Ferramentas .......................................................................................................... 268
12.2.3 Sadas ..................................................................................................................... 269
12.3 Fase do Diagrama de Fluxo de Dados ....................................................................................... 270
13. Scrum para Projetos Grandes ......................................................................................................... 271

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) VII


NDICE

13.1 Criar os Componentes do Projeto Grande .................................................................................. 274


13.1.1 Entradas ................................................................................................................. 275
13.1.2 Ferramentas .......................................................................................................... 278
13.1.3 Sada ...................................................................................................................... 279
13.2 Conduzir e Coordenar Sprints..................................................................................................... 283
13.2.1 Entradas ................................................................................................................. 284
13.2.2 Ferramentas .......................................................................................................... 286
13.2.3 Sadas ..................................................................................................................... 287
13.3 Preparar Release do Projeto Grande.......................................................................................... 289
13.3.1 Entradas ................................................................................................................. 290
13.3.2 Ferramentas .......................................................................................................... 290
13.3.3 Sadas ..................................................................................................................... 291
13.4 Impacto de Projetos Grandes aos Processos Fundamentais do Scrum ..................................... 292
14. SCALING SCRUM FOR THE ENTERPRISE .................................................................................. 297
14.1 Create Program or Portfolio Components ................................................................................... 301
14.1.1 Inputs ..................................................................................................................... 302
14.1.2 Tools ...................................................................................................................... 303
14.1.3 Outputs .................................................................................................................. 304
14.2 Review and Update Scrum Guidance Body ................................................................................ 305
14.2.1 Inputs ..................................................................................................................... 306
14.2.2 Tools ...................................................................................................................... 307
14.2.3 Outputs .................................................................................................................. 308
14.3 Create and Groom Program or Portfolio Backlog........................................................................ 309
14.3.1 Inputs ..................................................................................................................... 310
14.3.2 Tools ...................................................................................................................... 313
14.3.3 Outputs .................................................................................................................. 314
14.4 Coordinate Program or Portfolio Components ............................................................................ 315
14.4.1 Inputs ..................................................................................................................... 316
14.4.2 Tools ...................................................................................................................... 318
14.4.3 Outputs .................................................................................................................. 320
14.5 Retrospect Program or Portfolio Releases .................................................................................. 321

VIII 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


NDICE

14.5.1 Inputs ..................................................................................................................... 322


14.5.2 Tools ...................................................................................................................... 323
14.5.3 Outputs .................................................................................................................. 323
APNDICE A. VISO GERAL GIL ............................................................................................................ 324
APNDICE B. AUTORES E REVISORES DO GUIA SBOK ................................................................... 334
APPENDIX C. THIRD EDITION UPDATES................................................................................................. 336
REFERNCIAS ........................................................................................................................................... 338
GLOSSRIO ............................................................................................................................................... 340
INDEX.......................................................................................................................................................... 376

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) IX


LISTA DE FIGURAS

LISTA DE FIGURAS

Figura 1-1: Fluxo do Scrum para um Sprint ..................................................................................................... 2


Figura 1-2: Framework do Guia SBOK ........................................................................................................ 7
Figura 1-3: Princpios do Scrum ...................................................................................................................... 9
Figura 1-4: Organizao do Scrum................................................................................................................ 13
Figura 2-1: Transparncia em Scrum ............................................................................................................ 23
Figura 2-2: Inspeo em Scrum .................................................................................................................... 24
Figura 2-3: Adaptao em Scrum .................................................................................................................. 25
Figura 2-4: Desafios do Gerenceiamento de Projetos no Modelo Tradicional ............................................... 26
Figura 2-5: Objetivos de um time auto-organizado ........................................................................................ 28
Figura 2-6: Benefcios da Colaborao em Projetos Scrum .......................................................................... 30
Figura 2-7: Priorizao Baseada em Valor .................................................................................................... 33
Figura 2-8: Duraes Time-Box para Reunies do Scrum ............................................................................ 35
Figura 2-9: Scrum x O Modelo Tradicional Cascata (Waterfall)..................................................................... 37
Figura 3-1: Viso Geral dos Papis do Scrum............................................................................................... 42
Figura 3-2: As Perguntas feitas durante uma Reunio do Scrum de Scrums ............................................... 47
Figura 3-3: Caractersticas Desejveis para os Papis Centrais do Scrum .................................................. 49
Figura 3-4: Reunies do Scrum de Scrums (SOS) ........................................................................................ 52
Figura 3-5: Scrum em Toda a Organizao para Projetos, Programas e Portflios ...................................... 54
Figura 3-6: Etapa Tuckman de Desenvolvimento de Grupo .......................................................................... 58
Figura 3-7: Teoria de Maslow sobre Hierarquia das Necessidades .............................................................. 63
Figura 4-1: Entregando Valor em Scrum x Projetos Tradicionais .................................................................. 67
Figura 4-2: A Hierarquia de Responsabilidades da Justificativa de Negcios ............................................... 68
Figura 4-3: A Justificativa de Negcio e o Ciclo de Vida do Projeto .............................................................. 71
Figura 4-4: Anlise de Kano .......................................................................................................................... 75
Figura 4-5: Exemplo do Diagrama de Fluxo Cumulativo (DFC)..................................................................... 79
Figura 5-1: Diagrama de Fluxo de Incremento do Projeto ............................................................................. 87
Figura 5-2: Sequncia dos Critrios de Aceitao......................................................................................... 89
Figura 5-3: O Ciclo PDCA em Scrum ............................................................................................................ 93
Figura 6-1: Exemplo do Processo de Aprovao de Mudana .................................................................... 100

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) IX


LISTA DE FIGURAS

Figura 6-2: Atualizando o Backlog Priorizado do Produto com as Mudanas Aprovadas ........................... 100
Figura 6-3: As Caractersticas do Scrum para Adquirir Flexibilidade ........................................................... 102
Figura 6-4: O Motivo que leva os Stakeholders a Solicitar Mudanas......................................................... 103
Figura 6-5: O Motivo que leva o Time Central do Scrum a Solicitar Mudanas........................................... 104
Figura 6-6: Integrando Mudanas em Scrum .............................................................................................. 108
Figura 6-7: Impacto da Mudana Esperada na Durao do Sprint .............................................................. 110
Figura 6-8: Incorporando Mudanas em Portflio e Programa .................................................................... 114
Figura 7-1: Exemplo da rvore de Probabilidade ........................................................................................ 122
Figura 7-2: Exemplo do Grfico de Pareto .................................................................................................. 123
Figura 7-3: Exemplo da Matriz de Probabilidade e Impacto ........................................................................ 124
Figura 7-4: Processo para a Priorizao de Risco ...................................................................................... 126
Figura 7-5: Exemplo do Grfico de Risco Burndown ................................................................................... 128
Figura 7-6: O Manuseio de Riscos em Portflios e Programas ................................................................... 130
Figura 8-1: A Viso Geral de Iniciar ........................................................................................................... 135
Figura 8-2: A Viso Geral de Iniciar (Fundamentos) ................................................................................... 136
Figura 8-3: Criar a Viso do ProjetoEntradas, Ferramentas, e Sadas .................................................... 137
Figura 8-4: Criar a Viso do ProjetoDiagrama de Fluxo de Dados .......................................................... 138
Figura 8-5: O Processo de Anlise de Gap ................................................................................................. 143
Figura 8-6: Identificar o Scrum Master e o(s) Stakeholder(s)Entradas, Ferramentas, e Sadas .............. 145
Figura 8-7: Identificar o Scrum Master e o(s) Stakeholder(s)Diagrama de Fluxo de Dados .................... 146
Figura 8-8: Formar o Time ScrumEntradas, Ferramentas, e Sadas ..................................................... 152
Figura 8-9: Formar o Time ScrumDiagrama de Fluxo de Dados ............................................................. 153
Figura 8-10: Desenvolvimento de picosEntradas, Ferramentas, e Sadas ............................................ 158
Figura 8-11: Desenvolvimento de picosDiagrama de Fluxo de Dados .................................................. 159
Figura 8-12: Criar o Backlog Priorizado do ProdutoEntradas, Ferramentas, e Sadas ............................ 167
Figura 8-13: Criar o Backlog Priorizado do ProdutoDiagrama de Fluxo de Dados ................................. 168
Figura 8-14: Conduzir o Planejamento de ReleaseEntradas, Ferramentas, e Sadas ............................. 174
Figura 8-15: Conduzir o Planejamento de ReleaseDiagrama de Fluxo de Dados ................................... 175
Figura 8-16: Fase de IniciarDiagrama de Fluxo de Dados ....................................................................... 180
Figura 9-1: Viso Geral de Planejar e Estimar .......................................................................................... 183
Figura 9-2: Viso Geral de Planejar e Estimar (Fundamentos) ................................................................... 184
Figura 9-3: Criar as Estrias de UsurioEntradas, Ferramentas, e Sadas ............................................. 185

X 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


LISTA DE FIGURAS

Figura 9-4: Criar as Estrias de UsurioDiagrama de Fluxo de Dados ................................................... 186


Figura 9-5: Aprovar, Estimar, e Comprometer as Estrias de UsurioEntradas, Ferramentas, e Sadas 192
Figura 9-6: Aprovar, Estimar, e Comprometer as Estrias de UsurioDiagrama de Fluxo de Dados .... 192
Figura 9-7: Criar as TarefasEntradas, Ferramentas, e Sadas ................................................................ 198
Figura 9-8: Criar as TarefasDiagrama de Fluxo de Dados....................................................................... 198
Figura 9-9: Reunies de Planejamento de Tarefas ..................................................................................... 199
Figura 9-10: Estimar as TarefasEntradas, Ferramentas, e Sadas .......................................................... 203
Figura 9-11: Estimar as TarefasDiagrama de Fluxo de Dados .............................................................. 203
Figura 9-12: Criar o Backlog do SprintEntradas, Ferramentas, e Sadas ................................................ 207
Figura 9-13: Criar o Backlog do SprintDiagrama de Fluxo de Dados ...................................................... 208
Figura 9-14: Fase de Planejar e EstimarDiagrama de Fluxo de Dados ................................................... 212
Figura 10-1: Viso Geral de Implementar .................................................................................................... 215
Figura 10-2: Viso Geral de Implementar (Fundamentos)........................................................................... 216
Figura 10-3: Criar EntregveisEntradas, Ferramentas, e Sadas ............................................................ 217
Figura 10-4: Criar EntregveisDiagrama de Fluxo de Dados................................................................... 218
Figura 10-5: Scrumboard ............................................................................................................................. 219
Figura 10-6: Conduzir a Reunio DiriaEntradas, Ferramentas, e Sadas .............................................. 224
Figura 10-7: Conduzir a Reunio DiriaDiagrama de Fluxo de Dados .................................................... 225
Figura 10-8: Refinamento do Backlog Priorizado do ProdutoEntradas, Ferramentas, e Sadas.............. 230
Figura 10-9: Refinamento do Backlog Priorizado do ProdutoDiagrama de Fluxo de Dados .................... 231
Figura 10-10: Fase de ImplementarDiagrama de Fluxo de Dados .......................................................... 236
Figura 11-1: Viso Geral de Reviso e Retrospectiva ................................................................................. 239
Figura 11-2: Viso Geral de Reviso e Retrospectiva (Fundamentos)........................................................ 240
Figura 11-3: Convocar o Scrum de ScrumsEntradas, Ferramentas, e Sadas ........................................ 241
Figura 11-4: Convocar o Scrum de ScrumsDiagrama de Fluxo de Dados............................................... 241
Figura 11-5: Demonstrar e Validar o SprintEntradas, Ferramentas, e Sadas ......................................... 246
Figura 11-6: Demonstrar e Validar o SprintDiagrama de Fluxo de Dados ............................................... 247
Figura 11-7: Retrospectiva do SprintEntradas, Ferramentas, e Sadas ................................................... 251
Figura 11-8: Retrospectiva do SprintDiagrama de Fluxo de Dados ......................................................... 252
Figura 11-9: Fase de Reviso e RetrospectivaDiagrama de Fluxo de Dados.......................................... 257
Figura 12-1: Viso Geral da Release .......................................................................................................... 260
Figura 12-2: Viso Geral da Release (Fundamentos) ................................................................................. 261

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) XI


LISTA DE FIGURAS

Figura 12-3: Envio de EntregveisEntradas, Ferramentas, e Sadas ...................................................... 262


Figura 12-4: Envio de EntregveisDiagrama de Fluxo de Dados ........................................................... 262
Figura 12-5: Retrospectiva do ProjetoEntradas, Ferramentas, e Sada ................................................... 266
Figura 12-6: Retrospectiva do ProjetoDiagrama de Fluxo de Dados ....................................................... 266
Figura 12-7: Fase da ReleaseDiagrama de Fluxo de Dados ................................................................... 270

XII 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


LISTA DE TABELAS

LISTA DE TABELAS

Tabela 1-1: Resumo dos Processos do Scrum ............................................................................................. 16


Tabela 1-2: Scrum x O Modelo Tradicional de Gerenciamento de Projetos .................................................. 20
Tabela 3-1: Responsabilidade do Dono do Produto em Processos Scrum ................................................... 44
Tabela 3-2: Responsabilidades do Scrum Master em Processos Scrum ...................................................... 46
Tabela 3-3: Responsabilidades do Time Scrum em Processos do Scrum .................................................... 48
Tabela 3-4: Resumo das Responsabilidades Relevantes Organizao ..................................................... 56
Tabela 4-1: Frmulas de Valor Agregado ...................................................................................................... 77
Tabela 4-2: Resumo das Responsabilidades Relevantes a Justificativa de Negcio .................................... 81
Tabela 5-1: Resumo das Responsabilidades Relevantes de Qualidade ....................................................... 94
Tabela 6-1: Resumo das Responsabilidades Relevantes de Mudana ....................................................... 115
Tabela 7-1: Resumo das Responsabilidades Relevantes de Risco ............................................................ 131

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) XIII


XIV 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)
1 INTRODUO

1. INTRODUO
Um guia para o conhecimento em Scrum (Guia SBOK), fornece diretrizes para o sucesso da 1
implementao do Scrum, a metodologia gil mais popular de gerenciamento de projetos e de
desenvolvimento de produtos. Este livro fornece uma estrutura abrangente, que inclui os princpios,
aspectos e os processos do Scrum.

Scrum, tal como definido no Guia SBOK aplicvel para:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou qualquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode se referir a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

O primeiro captulo descreve a finalidade e o framework do Guia SBOK e fornece uma introduo dos
principais conceitos do Scrum. Contm uma viso geral dos princpios, aspectos e processos do Scrum. O
captulo 2 refere-se aos seis princpios do Scrum, que so a base do framework Scrum. Os captulos 3 a 7
so referentes aos cinco aspectos do Scrum que devem ser abordados ao longo de qualquer projeto:
organizao, justificativa de negcio, qualidade, mudana e risco. Os captulos de 8 a 12 so referentes aos
19 processos do Scrum envolvidos na criao de um projeto Scrum. Estes processos fazem parte das cinco
fases do Scrum: Iniciar; Planejar e Estimar; Implementar; Reviso e Retrospectiva; e Release. Estas fases
descrevem em detalhes as entradas e sadas associadas a cada processo e as vrias ferramentas que
podem ser utilizadas em cada processo. Algumas entradas, ferramentas e sadas so obrigatrias e so
identificadas como tal; outras so opcionais, dependendo do projeto em especfico, dos requisitos
organizacionais e/ou diretrizes estabelecidas pela organizao do Scrum Guidance Body (SGB).
Finalmente, o Apndice A contm uma viso geral do Manifesto gil (Fowler e Highsmith, 2001), e uma
anlise dos diversos mtodos geis, para aqueles que querem mais informaes sobre gil.

Este captulo est dividido nas seguintes sees:

1.1 Viso geral do Scrum

1.2 Por que usar Scrum?

1.3 Finalidade do Guia SBOK

1.4 Framework do Guia SBOK

1.5 Scrum x O Modelo Tradicional de Gerenciamento de Projetos

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 1


1 INTRODUO

1.1 Viso geral do Scrum


Um projeto Scrum envolve um esforo de colaborao para criar um novo produto, servio ou qualquer
outro resultado, conforme definido no Declarao da Viso do Projeto. Os projetos so afetados pelas
restries de tempo, custo, escopo, qualidade, recursos, capacidade de organizao, e outras limitaes
que os tornam difceis de planejar, implementar, gerenciar e, finalmente, de alcanar o sucesso. No entanto,
o sucesso da implementao dos resultados de um projeto concludo, oferece benefcios comerciais
significativos para uma organizao. Portanto, importante que as organizaes selecionem e pratiquem
uma metodologia de gerenciamento de projeto adequada.

O Scrum uma das metodologias geis mais populares. uma metodologia de adaptao, iteratividade,
rpidez, flexibilidade e eficincia, projetada para fornecer um valor significativo de forma rpida durante todo
o projeto. O Scrum garante a transparncia na comunicao e cria um ambiente de responsabilidade
coletiva e progresso contnuo. O framework Scrum, conforme definido no Guia SBOK, estruturado de tal
forma que apoia o desenvolvimento de produtos e servios em todos os tipos de indstrias e em qualquer
tipo de projeto, independentemente de sua complexidade.

Um dos pontos fortes do Scrum est na utilizao de times multifuncionais, auto-organizados, e


empoderados, que dividem o trabalho em ciclos curtos e concentrados chamados Sprints.

A figura 1-1 fornece uma viso geral do fluxo de um projeto Scrum.

Figura 1-1: Fluxo do Scrum para um Sprint

O ciclo do Scrum comea com uma Reunio do Stakeholder, durante o qual se cria a Viso do Projeto. O
Dono do Produto em seguida, desenvolve um Backlog Priorizado do Produto que contm uma lista de
prioridades de requisitos de produtos e de negcio, descritos na forma de Estria de Usurio. Cada Sprint
comea com uma Reunio de Planejamento do Sprint durante o qual as Estrias de Usurio de alta

2 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

prioridade so consideradas para a incluso no Sprint. Um Sprint normalmente dura entre uma e seis
semanas e envolve o Time Scrum, trabalhando na criao de entregas potencialmente utilizveis ou
melhorias de produtos. Durante o Sprint, so realizadas Reunies Dirias, curtas e altamente focadas onde
os membros do time discutem o progresso dirio. Perto do final do Sprint, uma Reunio de Planejamento do
Sprint realizada, na qual o Dono do Produto e os Stakeholders recebem uma demonstrao dos 1
entregveis. O Dono do Produto apenas aceita os entregveis se os mesmos cumprirem os Critrios de
Aceitao pr-definidos. O ciclo Sprint termina com uma Reunio de Retrospectiva do Sprint, onde o time
apresenta maneiras de melhorar os seus processos e o seu desempenho, medida que avanam para o
prximo Sprint.

1.1.1 Breve Histria do Scrum

Em meados dos anos 80, Hirotaka Takeuchi e Nonaka Ikujiro definiram uma estratgia flexvel e completa
para o desenvolvimento de produtos, onde o time de desenvolvimento trabalha como uma unidade, para
alcanar um objetivo comum. Eles descreveram uma abordagem inovadora para o desenvolvimento de
produtos, que chamaram de abordagem holstica ou "rugby", "onde um time tenta percorrer a distncia
como uma unidade, passando a bola para frente e para trs." Eles basearam esta abordagem nos estudos
de caso de diversas indstrias. Takeuchi e Nonaka propem que o desenvolvimento do produto no deve
ser como uma sequncia de corrida de revezamento, mas sim semelhante ao jogo de rugby em que o time
trabalha em conjunto, passando a bola para frente e para tras movendo-se atravs do campo como uma
unidade. O conceito de rugby em "Scrum" (onde um grupo de jogadores se renem para reiniciar o jogo) foi
introduzido neste artigo para descrever a proposta dos autores de que o desenvolvimento do produto deve
envolver "o movimento de Scrum campo abaixo " (moving the Scrum downfield).

Ken Schwaber e Jeff Sutherland desenvolveram o conceito do Scrum e sua aplicabilidade para o
desenvolvimento de software em uma apresentao durante a conferncia Object-Oriented Programming,
Systems, Languages & Applications (OOPSLA) em 1995 em Austin, Texas. Desde ento, vrios
profissionais, especialistas e autores do Scrum continuam a refinar o conceito e a metodologia do Scrum.
Nos ltimos anos, o Scrum tem crescido em popularidade e agora o mtodo de desenvolvimento de
projetos preferido por muitas organizaes, no mundo inteiro.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 3


1 INTRODUO

1.2 Por que usar o Scrum?


Algumas das principais vantagens da utilizao do Scrum, em qualquer projeto, so:

1. AdaptabilidadeO Controle de Processos Empricos e a Entrega Iterativa fazem com que os


projetos sejam adaptveis e abertos incorporao de mudanas.

2. Transparncia Todos as fontes de informaes, tais como, o Scrumboard e o Grfico Burndown


do Sprint, so compartilhadas gerando um ambiente de trabalho aberto.

3. Feedback ContnuoO Feedback Contnuo fornecido atravs de processos denominados como


Conduzir a Reunio Diria e Demonstrar e Validar o Sprint.

4. Melhoria ContnuaAs entregas melhoram progressivamente, Sprint por Sprint, atravs do


processo de Refinamento do Backlog Priorizado do Produto.

5. Entrega Contnua de ValorOs processos iterativos permitem a entrega contnua de valor to


frequente quanto exigido pelo cliente, atravs do processo de Envio de Entregveis.

6. Ritmo SustentvelOs processos do Scrum so projetados de tal forma, que as pessoas


envolvidas trabalham em um ritmo sustentvel, podendo, em teoria, continuar indefinidamente.

7. Entrega Antecipada de Alto ValorO processo de Criar o Backlog Priorizado do Produto garante
que as exigncias de maior valor ao cliente sejam atendidas primeiramente.

8. Processo de Desenvolvimento EficienteO Time-boxing e a minimizao de trabalho no


essencial conduzem a nveis mais altos de eficincia.

9. MotivaoOs processos de Conduzir a Reunio Diria e de Retrospectiva do Sprint conduzem a


nveis mais altos de motivao entre os colaboradores.

10. Soluo de Problemas de Forma mais RpidaA colaborao e a colocation de times


multifuncionais conduzem a resoluo de problemas de maneira mais rpida.

11. Entregas EficazesO processo de Criar o Backlog Priorizado do Produto, e as revises


peridicas aps a gerao de entregveis, garantem entregas eficazes para o cliente.

12. Com Foco no ClienteUma abordagem colaborativa com stakeholders e a nfase no valor de
negcio, garantem uma estrutura orientada para o cliente.

13. Ambiente de Alta ConfianaOs processos de Conduzir a Reunio Diria e de Retrospectiva do


Sprint promovem a transparncia e a colaborao, resultando em um ambiente de trabalho de alta
confiana, e garantindo baixo atrito entre os colaboradores.

14. Responsabilidade ColetivaO processo de Aprovar, Estimar e Comprometer as Estrias de


Usurio permite que os membros do time se sintam responsveis pelo projeto e por seu trabalho,
resultando em uma qualidade melhor.

4 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

15. Alta VelocidadeUma estrutura de colaborao que permite que os times multifuncionais
altamente qualificados, atinjam o seu pleno potencial e alta velocidade.

16. Ambiente InovadorOs processos de Retrospectiva do Sprint e de Retrospectiva do Projeto 1


criam um ambiente de introspeco, aprendizagem e adaptabilidade, que levam a um ambiente de
trabalho inovador e criativo.

1.2.1 Escalabilidade de Scrum

Para serem eficazes, o tamanho ideal dos Times Scrum deve ser de seis dez membros. Esta prtica pode
induzir concepo errnea de que o Scrum pode ser utilizado apenas para projetos pequenos. Ao
contrrio, o Scrum pode ser facilmente escalado para o uso eficaz em grandes projetos. Em situaes em
que o tamanho do Time Scrum ultrapassa dez pessoas, vrios Times Scrum podem ser formados para
trabalhar no projeto. O processo de Convocar o Scrum de Scrums facilita a coordenao entre os Times
Scrum, permitindo a implementao eficaz em projetos maiores.

Os projetos grandes ou complexos so frequentemente implementados como parte de um programa ou


portflio. O modelo Scrum tambm pode ser aplicado para gerenciar programas e portflios. A abordagem
lgica das orientaes e princpios desse modelo podem ser usadas para gerenciar projetos de todos os
tamanhos, abrangendo regies geogrficas e organizaes. Grandes projetos podem ter mltiplos Scrum
Teams trabalhando em paralelo, sendo necessrio sincronizar e facilitar o fluxo de informaes e melhorar
a comunicao. Convocar o Scrum de Scrums o processo que garante essa sincronizao. Todos os
Times Scrum so representados nesta reunio com o objetivo de fornecer atualizaes sobre o progresso,
discutir os desafios enfrentados durante o projeto, e coordenar as atividades. No h regras estabelecidas
quanto frequncia destas reunies. Os fatores que determinam a frequncia so a quantidade de
dependncia entre os times, o tamanho do projeto, o nvel de complexidade e recomendaes do Scrum
Guidance Body.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 5


1 INTRODUO

1.3 Objetivo do Guia SBOK


Nos ltimos anos, tornou-se evidente que as organizaes que utilizam Scrum como modelo para a
implementao de projetos, obtm consistentemente alto Retorno sobre Investimento. O foco do Scrum na
entrega orientada a valor ajuda os Times Scrum a entregarem resultados o mais rpido que for possvel
durante todo o projeto.

O Guia SBOK foi desenvolvido no sentido de criar um guia indispensvel para as organizaes e
profissionais da rea de gerenciamento que desejam implementar projetos Scrum, bem como para aqueles
que j implementaram e desejam melhorar seus processos, baseado na experincia adquirida atravs de
milhares de projetos em uma variedade de organizaes e indstrias. As contribuies de muitos
especialistas em Scrum e de profissionais de gerenciamento de projetos foram consideradas no seu
desenvolvimento.

O Guia SBOK especialmente valioso:

para os membros do Time Scrum, incluindo:


Os Donos do Produto que desejam compreender plenamente o modelo Scrum e,
particularmente as preocupaes dos clientes ou stakeholders com assuntos que
envolvem a justificativa de negcio, qualidade, mudanas e aspectos de risco associados
com os projetos Scrum.
Os Scrum Masters que querem aprender sobre o seu papel no acompanhamento da
implementao do modelo Scrum em projetos.
Os membros do Time Scrum que desejam compreender melhor os processos do Scrum e
ferramentas associadas que podem ser utilizadas para criar produtos ou servios do
projeto.
como um guia completo para todos os profissionais que j trabalham em projetos Scrum em
qualquer organizao ou indstria.
como uma fonte de referncia para quem interage com o Time Central do Scrum, incluindo, mas
no limitado-se ao: Dono do Produto do Portflio, Scrum Master, Scrum Master do Portflio, Dono
do Produto do Programa, Scrum Master do Programa, Scrum Guidance Body, e Stakeholders
(como patrocinador, cliente e usurios).
como um manual para quem no tem experincia anterior ou conhecimento sobre o modelo Scrum,
mas que quer aprender mais sobre o assunto.

O contedo do Guia do SBOK tambm til para pessoas que esto se preparando para os seguintes
exames de certificao da SCRUMstudy:

Scrum Developer Certified (SDC)


Scrum Master Certified (SMC)
Agile Expert Certified (AEC)
Scrum Product Owner Certified (SPOC)
Expert Scrum Master (ESM)

6 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

1.4 Estrutura do Guia SBOK


O Guia SBOK dividido em trs seguintes reas:

1. Princpios que so referidos no Captulo 2, e que expandem-se aos seis princpios que formam a 1
fundao sobre a qual o Scrum se baseia.

2. Aspectos abordados nos captulos 3 a 7, que descrevem os cinco aspectos que so considerados
importantes para todos os projetos Scrum.

3. Processos que so abrangidos nos captulos 8 a 12, e que incluem os dezenove processos do
Scrum e as suas entradas, ferramentas e sadas.

A figura 1-2 ilustra o framework do Guia SBOK, monstrando que os princpios, aspectos e processos
interagem uns com os outros, e que so de igual importncia para tentar obter-se uma melhor compreenso
do framework Scrum.

Figura 1-2: Framework do Guia SBOK

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 7


1 INTRODUO

1.4.1 Como Utilizar o Guia SBOK?

O Guia SBOK pode ser usado como uma referncia e guia de conhecimento, tanto para profissionais com
experincia em Scrum e na rea de desenvolvimento de produtos e servios, quanto para as pessoas que
no tm experincia prvia ou conhecimento em Scrum ou de metodologias de gerenciamento de projetos.
O seu contedo separado em trs funes bsicas do Time Central do Scrum: Scrum Master, Dono do
Produto e Time Scrum.

Os captulos que abranjem os seis princpios do Scrum (Captulo 2) e os cinco aspectos do Scrum (captulo
3-7), incluem um Guia de Papis. Este guia fornece orientao sobre a relevncia de cada seo no
captulo para as funes do Time Central do Scrum.

Com a finalidade de facilitar a aplicao em prtica do framework Scrum, o Guia SBOK tem entradas,
ferramentas e sadas, claramente diferenciadas e obrigatrias, no-obrigatrias ou opicionais. As entradas,
ferramentas e sadas indicadas por asteriscos (*) so obrigatrias e as sem asteriscos so opcionais.
Recomenda-se que as pessoas que esto comeando a aprender sobre o Scrum, concentrem-se
principalmente nas entradas, ferramentas e sadas que so obrigatrias, enquanto os profissionais mais
experientes devem ler todos os captulos do processo.

8 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

1.4.2 Princpios do Scrum

Os Princpios do Scrum so as diretrizes fundamentais para a aplicao do framework Scrum e devem


obrigatoriamente serem usados em todos os projetos Scrum. Os seis princpios do Scrum apresentados no
segundo captulo so:
1

1. Controle de Processos Empricos


2. Auto-organizao
3. Colaborao
4. Priorizao Baseada em Valor
5. Time-boxing
6. Desenvolvomento Iterativo

A figura 1-3 ilustra os seis princpios do Scrum.

Figura 1-3: Princpios do Scrum

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 9


1 INTRODUO

Os Princpios do Scrum podem ser aplicados a qualquer tipo de projeto em qualquer organizao e devem
ser seguidos corretamente para assegurar a aplicao efetiva do framework Scrum. Os princpios do Scrum
no so negociveis e devem ser aplicados conforme especificado no Guia SBOK. Mantendo os
princpios intactos e usando-os de forma adequada demonstra-se confiana no framework Scrum em
relao realizao dos objetivos do projeto. Os aspectos e processos do Scrum, no entanto, podem ser
modificados para atender aos requisitos do projeto ou da organizao.

1. Controle de Processos EmpricosEsse princpio enfatiza a filosofia central do Scrum com base
em trs ideias principais: transparncia, inspeo e adaptao.

2. Auto-organizaoEsse princpio est focado nos colaboradores atuais de uma organizao, que
entregam significamente um maior valor quando so auto-organizados e isto resulta em times mais
satisfeitos e responsabilidade compartilhada; e em um ambiente inovador e criativo que mais
propcio ao crescimento.

3. ColaboraoEsse princpio concentra-se nas trs dimenses bsicas relacionadas com o


trabalho colaborativo: conscincia, articulao e apropriao. Tambm defende o gerenciamento
de projetos como um processo de criao de valor compartilhado, com times trabalhando e
interagindo em conjunto para atingirem melhores resultados.

4. Priorizao Baseada em ValorEsse princpio destaca o foco do Scrum em entregar o mximo


de valor de negcio possvel, durante todo o projeto.

5. Time-boxingEsse princpio descreve como o tempo considerado uma restrio limitada em


Scrum, e como ele usado para ajudar a gerenciar o planejamento e execuo do projeto com
eficcia. Os elementos de Time-boxed em Scrum incluem os Sprints, as Reunies Dirias, a
Reunio de Planejamento do Sprint, e a Reunio de Reviso do Sprint.

6. Desenvolvimento IterativoEsse princpio define o desenvolvimento iterativo e enfatiza como


administrar melhor as mudana e criar produtos que atendam s necessidades do cliente. Tambm
delineia as responsabilidades do Dono do Produto e da organizao, com relao ao
desenvolvimento iterativo.

10 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

1.4.3 Aspectos do Scrum

Os aspectos do Scrum devem ser destacados e gerenciados durante o projeto Scrum. Os cinco aspectos
do Scrum apresentados nos captulos 3 a 7 so:
1

1.4.3.1 Organizao

Entender os papis definidos e suas responsabilidades em um projeto Scrum muito importante para
garantir o sucesso na implementao do Scrum.

Os papis do Scrum so divididos em duas categorias:

1. Papis Centraisso aqueles papis obrigatoriamente necessrios para o desenvolvimento do


produto ou servio do projeto. As pessoas a que estes papis so atribudos esto totalmente
comprometidas com o projeto e so responsveis pelo sucesso de cada iterao, e do projeto
como um todo.

Estes papis so:

Dono do Produto: responsvel por alcanar o maior valor de negcio para o projeto, e
tambm responsvel pela coordenao das necessidades dos clientes e pela manuteno
da justificativa de negcio para o projeto. O Dono do Produto representa a voz do cliente.

Scrum Master: um facilitador, que garante ao Time Scrum o fornecimento de um


ambiente propcio para concluir o projeto com sucesso. O Scrum Master guia, facilita e
ensina as prticas do Scrum para todos os envolvidos no projeto; remove os impedimentos
encontrados pelo time; e, assegura que os processos do Scrum estejam sendo seguidos.

Time Scrum: o grupo ou time responsvel pelo desenvolvimento das entregas do


projeto e por entender os requisitos especificados pelo Dono do Produto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 11


1 INTRODUO

2. Papis No-Essenciaisso os papis que no so obrigatoriamente necessrios para o projeto


Scrum. Podem incluir os membros dos times que esto interessados no projeto, que no tem
nenhum papel formal no time do projeto e que podem interagir com o time, mas no podem ser
responsveis pelo sucesso do projeto. Os Papis No-Essenciais devem ser considerados em
qualquer projeto Scrum.

Papis No-Essenciais incluem:

Stakeholder(s): um termo coletivo que inclui clientes, usurios e patrocinadores, que


muitas vezes interagem com o Time Central do Scrum e que influenciam o projeto durante
todo o seu desenvolvimento. Mais importante ainda, para os stakeholders que o projeto
produz os benefcios colaborativos.

Scrum Guidance Body (SGB): um recurso opcional, que geralmente consiste em um


conjunto de documentos e/ou um grupo de especialistas que esto geralmente envolvidos
na definio de objetivos relacionados com a qualidade, regulamentaes
governamentais, de segurana e outros parmetros-chave da organizao. O SGB orienta
o trabalho realizado pelo Dono do Produto, Scrum Master e pelo Time Scrum.

Fornecedores: incluem indivduos ou organizaes externas, que fornecem produtos e/ou


servios que no esto dentro das competncias essenciais da organizao do projeto.

Dono do Produto Chefe: um papel desempenhado em projetos maiores, com vrios


Times Scrum. Este papel responsvel por facilitar o trabalho dos Donos do Produtos e
por manter a justificativa de negcio durante um projeto grande.

Scrum Master Chefe: responsvel pela coordenao das atividades relacionadas com o
Scrum em projetos grandes, que podem exigir que vrios Times Scrum trabalhem em
paralelo.

A figura 1-4 ilustra a Estrutura da Organizao do Scrum.

12 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

Figura 1-4: Organizao do Scrum

O aspecto da Organizao do Scrum tambm aborda os requisitos da estrutura do time para implementar o
Scrum em programas e portflio.

1.4.3.2 Justificativa de Negcio

importante que a organizao realice uma avaliao adequada do negcio antes de iniciar qualquer
projeto. Isso ajuda os tomadores-chave de deciso a entender a necessidade do negcio para uma
mudana ou para um novo produto ou servio, a justificativa para seguir adiante com o projeto e sua
viabilidade.

A Justificativa de Negcio em Scrum baseada no conceito de entrega dirigida a valor. Uma das
caractersticas-chave de qualquer projeto a incerteza dos resultados. impossvel garantir o sucesso do
projeto, independentemente do seu tamanho ou de sua complexidade. Diante dessa incerteza do sucesso,
o Scrum tenta comear a entregar resultados no projeto o mais rpido possvel. Esta entrega antecipada de
resultados, e consequentemente, de valor, oferece uma oportunidade para reinvestimento e comprova o
valor do projeto aos stakeholders.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 13


1 INTRODUO

A adaptabilidade do Scrum permite que os objetivos e os processos do projeto sejam alterados caso
ocorram modificaes na justificativa de negcio. importante notar que embora o Dono do Produto seja o
principal responsvel pela justificativa de negcio, outros membros do time tambm contribuem
significativamente.

1.4.3.3 Qualidade

Em Scrum, a qualidade definida como a capacidade dos produtos (ou de entregveis concludos) em
atender os Critrios de Aceitao e em alcanar o valor de negcio esperado pelo cliente.

Para garantir que um projeto satisfaa os requisitos de qualidade, o Scrum adota uma abordagem de
Melhoria Contnua em que o time aprende com a experincia e o engajamento dos stakeholders, a manter o
Backlog Priorizado do Produto constantemente atualizado com qualquer mudana que haja nos requisitos.
O Backlog Priorizado do Produto apenas ser concludo no encerramento ou trmino do projeto. Qualquer
alterao nos requisitos refletem em mudanas no ambiente de negcios, interno ou externo, e permite que
o time trabalhe e se adapte continuamente para atingir esses requisitos.

J que o Scrum exige que o trabalho seja feito em incrementos ao longo dos Sprints, isso faz com que os
erros ou defeitos sejam notados mais cedo, atravs de repetitivos testes de qualidade durante o seu
desenvolvimento, ao invs de quando o produto final ou servio est quase concludo. Alm disso, as
tarefas importantes relacionadas com a qualidade (por exemplo, desenvolvimento, testes e documentao)
so completadas pelo mesmo time, como parte do mesmo Sprint. Isso garante que a qualidade seja
inerente a qualquer entregvel desenvolvido como parte de um Sprint. Estes entregveis do projeto Scrum,
que so potencialmente utilizveis, so referidos como Pronto.

Portanto, a Melhoria Contnua com testes repetitivos otimiza a probabilidade de atingir-se os nveis de
qualidade esperados em um projeto Scrum. As discusses constantes entre o Time Central de Scrum e os
stakeholders (incluindo clientes e usurios), com relao aos incrementos reais do produto a serem
entregues ao final de cada Sprint, garante que a diferena entre os resultados reais produzidos durante o
projeto, e as expectativas dos clientes com relao ao mesmo sejam constantemente reduzidas.

O Scrum Guidance Body tambm pode fornecer diretrizes sobre a qualidade, que podem ser relevantes a
todos os projetos Scrum na organizao.

1.4.3.4 Mudana

Todo o projeto, independentemente do mtodo ou do framework utilizado, est sujeito a mudanas.


imperativo que os membros do time do projeto compreendam que os processos de desenvolvimento Scrum
so projetados para aceitar estas mudanas. As organizaes devem tentar maximizar os benefcios
decorrentes das mudanas e minimizar quaisquer impactos negativos, por meio de processos diligentes de
gerenciamento de mudana, de acordo com os princpios do Scrum.

14 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

Um princpio fundamental do Scrum reconhecer que 1) os stakeholders (por exemplo, clientes, usurios e
patrocinadores) mudam de ideia muitas vezes durante o projeto, sobre o que eles querem e precisam, e 2)
muito difcil, se no impossvel, para os stakeholders definirem todos os requisitos durante o incio do
projeto.
1
Para projetos Scrum, as mudanas so bem-vindas, atravs de Sprints iterativos e curtos que incorporam o
feedback do cliente sobre cada entregvel do Sprint. Isto permite que o cliente interaja regularmente com os
membros do Time Scrum, podendo verificar as entregas assim que as mesmas forem concludas, e
podendo alterar os requisitos, se necessrio, o quanto antes no Sprint.

Alm disso, os times de gesto de programas ou de portflio podem responder as Solicitaes de Mudana
pertencentes aos projetos Scrum aplicveis ao seu nvel.

1.4.3.5 Risco

O Risco definido como um evento incerto ou um conjunto de eventos que podem afetar os objetivos de
um projeto e podem contribuir para o seu sucesso ou fracasso. Os riscos que podem ter um impacto
positivo sobre o projeto so conhecidos como oportunidades, enquanto que as ameaas so riscos que
podem afetar o projeto de uma forma negativa. O gerenciamento dos riscos deve ser feito de forma
proativa, sendo um processo iterativo, que deve comear no incio do projeto e continuar durante todo o seu
ciclo de vida. O processo de gerenciamento dos riscos deve seguir alguns passos padronizados, para
garantir que os riscos sejam identificados, avaliados, e que um plano de ao seja definido e colocado em
prtica apropriadamente.

Os riscos devem ser identificados, avaliados e respondidos com base em dois fatores: de probabilidade de
ocorrncia de cada risco, e de impacto potencial em caso de tal ocorrncia. Os riscos de alta probabilidade
e valor impactante (determinado atravs da multiplicao dos dois fatores) devem ser tratados antes
daqueles com valor relativamente menor. Em geral, uma vez que o risco seja identificado, importante
compreender as suas possveis causas e os potenciais efeitos casoo mesmo venha a ocorrer.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 15


1 INTRODUO

1.4.4 Processos do Scrum

Os Processos do Scrum abordam as atividades e o fluxo especfico de um projeto Scrum. No total, existem
dezenove processos que esto agrupados em cinco fases. Estas fases so apresentadas nos captulos 8 a
12 deste guia, de acordo com a Tabela 1-1.

Captulo Fase Processos

1. Criar a Viso do Projeto


2. Identificar o Scrum Master e o(s) Stakeholder(s)
3. Formar o Time Scrum
8 Iniciar
4. Desenvolver os picos
5. Criar o Backlog Priorizado do Produto
6. Conduzir o Planejamento da Release

7. Criar as Estrias de Usurio


8. Aprovar, Estimar, e Comprometer as Estrias de Usurio
9 Planejar e Estimar 9. Criar as Tarefas
10. Estimar as Tarefas
11. Criar o Backlog do Sprint

12. Criar os Entregveis


10 Implementar 13. Conduzir a Reunio Diria
14. Refinamento do Backlog Priorizado do Produto

15. Convocar o Scrum de Scrums


11 Reviso e Retrospectiva 16. Demonstrar e Validar o Sprint
17. Retrospectiva do Sprint

18. Enviar os Entregveis


12 Release
19. Retrospectiva do Projeto

Tabela 1-1: Resumo dos Processos do Scrum

Estas fases descrevem cada processo em detalhe, incluindo suas entradas, ferramentas e sadas. Em cada
processo, algunas entradas, ferramentas e sadas so necessrias (seguidas por asterisco [*] depois de
seus nomes), enquanto que outras so opcionais. A incluso das entradas, ferramentas e/ou sadas
opcionais dependem das particularidades do projeto, organizao ou indstria. As entradas, ferramentas e
sadas indicadas como obrigatrias so importantes para o sucesso da implementao do Scrum em
qualquer organizao.

16 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

1.4.4.1 Iniciar

1. Criar a Viso do ProjetoNeste processo, o Caso do Negcio do Projeto revisado para criar uma
Declarao da Viso do Projeto que servir como inspirao e orientao para todo o projeto. O
Dono do Produto identificado nesse processo.
1

2. Identificar o Scrum Master e o(s) Stakeholder(s)Neste processo, o Scrum Master e o(s)


Stakeholder(s) so identificados com base em uma seleo especfica de critrios.

3. Formar o Time ScrumNeste processo, os membros do Time Scrum so identificados.


Normalmente, o Dono do Produto tem a responsabilidade primria de selecionar os membros do
time, mas frequentemente conta com o auxlio do Scrum Master.

4. Desenvolver os picosNeste processo, a Declarao da Viso do Projeto serve como base para
o desenvolvimento dos picos. Reunies do Grupo de Usurios podem ser realizadas para discutir
picos apropriados.

5. Criar o Backlog Priorizado do ProdutoNeste processo, picos so refinados, processados e, em


seguida priorizados, para que um Backlog Priorizado do Produto seja criado para o projeto. Os
Critrios de Pronto tambm so estabelecidos neste momento.

6. Conduzir o Planejamento da ReleaseNeste processo, o Time Central do Scrum revisa as


Estrias de Usurio no Backlog Priorizado do Produto para desenvolver um Cronograma de
Planejamento da Release, que essencialmente um cronograma de implementao faseado que
pode ser compartilhado com os stakeholders do projeto. A Durao do Sprint tambm
determinada neste processo.

1.4.4.2 Planejar e Estimar

7. Criar as Estrias de UsurioNeste processo, as Estrias de Usurio so criadas e os seus


respectivos Critrios de Aceitao da Estria de Usurio. As Estrias de Usurio so geralmente
escritas pelo Dono do Produto e so projetadas para assegurar que os requisitos do cliente
estejam claramente descritos, e que podem ser totalmente compreendidos por todos os
Stakeholders. Exerccios de Escrita da Estria de Usurio podem ser realizados, envolvendo os
membros do Time Scrum, na criao das Estrias de Usurio. As Estrias de Usurio so
incorporadas ao Backlog Priorizado do Produto.

8. Aprovar, Estimar e Comprometer as Estrias de UsurioNeste processo, o Dono do Produto


aprova as Estrias de Usurio para o Sprint. Em seguida, o Scrum Master e o Time Scrum
estimam os esforos necessrios para desempenhar as funes descritas em cada Estria de

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 17


1 INTRODUO

Usurio, e o Time Scrum compromete-se a entregar os requisitos do cliente sob a forma de


Estrias de Usurio Aprovadas, Estimadas e Comprometidas.

9. Criar as TarefasNeste processo, as Estrias de Usurio Aprovadas, Estimadas e Comprometidas


so divididas em tarefas especficadas e agregadas a uma Lista de Tarefas. Muitas vezes, uma
Reunio de Planejamento de Tarefas realizada para essa finalidade.

10. Estimar as TarefasNeste processo, o Time Central de Scrum durante a Reunio de


Planejamento de Tarefas, estima os esforos necessrios para a realizao de cada tarefa inclusa
na Lista de Tarefas. O resultado deste processo um Lista de Tarefas de Estimativa de Esforo.

11. Criar o Backlog do SprintNeste processo, o Time Central de Scrum realiza uma Reunio de
Planejamento do Sprint, onde o grupo cria um Backlog do Sprint que contm todas as tarefas para
serem concludas durante o Sprint.

1.4.4.3 Implementar

12. Criar os EntregveisNeste processo, o Time Scrum trabalha nas tarefas do Backlog do Sprint,
para criar os Entregveis do Sprint. Um Scrumboard frequentemente utilizado para acompanhar
o trabalho e atividades que esto sendo realizadas. Questes ou problemas enfrentados pelo Time
Scrum podem ser atualizados no Registro de Impedimentos.

13. Conduzir a Reunio DiriaNeste processo, diariamente, realiza-se uma reunio Time-boxed,
altamente focada chamada de Reunio Diria. Este o momento que os membros do Time Scrum
podem atualizar uns aos outros sobre os seus progressos e quaisquer Impediments que possam
estar enfrentando.

14. Refinamento do Backlog Priorizado do ProdutoNeste processo, o Backlog Priorizado do Produto


continuamente atualizado e mantido. Uma Reunio de Reviso do Backlog Priorizado do Produto
pode ser realizada, em que quaisquer mudanas ou atualizaes no Backlog so discutidas e
incorporadas adequadamente ao Backlog Priorizado do Produto.

1.4.4.4 Reviso e Retrospectiva

15. Convocar o Scrum dos ScrumsNeste processo, os representantes do Time Scrum so


convocados para as Reunies do Scrum de Scrums (SoS), em intervalos pr-determinados ou
conforme necessrio, para colaborar e acompanhar seus respectivos progressos, impedimentos, e
as dependncias entre si. Isso relevante apenas em projetos grandes onde vrios Times Scrum
esto envolvidos.

18 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


1 INTRODUO

16. Demonstrar e Validar o SprintNeste processo, o Time Scrum apresenta os Entregveis do Sprint
ao Dono do Produto e aos stakeholders relevantes, em uma Reunio de Reviso do Sprint. O
objetivo dessa reunio garantir a aprovao e aceitao do Dono do Produto para os Entregveis
desenvolvidos no Sprint.
1
17. Retrospectiva do SprintNeste processo, o Scrum Master e o Time Scrum se renem para discutir
as lies aprendidas durante o Sprint. Esta informao documentada como lies aprendidas,
que podero ser aplicadas em Sprints futuros. Muitas vezes, como resultado dessa reunio, podem
ocorrer Pontos de Melhoria Aconcordados ou Recomendaes do Scrum Guidance Body
Atualizadas.

1.4.4.5 Release

18. Envio de EntregveisNeste processo, os Entregveis Aceitos so entregues ou transferidos aos


Stakeholders relevantes. Um acordo formal chamado de Contrato de Prestao de Trabalho,
documenta a finalizao com sucesso do Sprint.

19. Retrospectiva do ProjetoNeste processo, que completa o projeto, os stakeholders e Time Central
do Scrum, renem-se para fazer uma retrospectiva do projeto e, identificar, documentar e
internalizar as lies aprendidas. Muitas vezes, essas lies levam a documentao dos Pontos de
Melhoria Acordados, a serem implementados em projetos futuros.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 19


1 INTRODUO

1.5 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


A tabela 1-2 resume muitas das diferenas entre o Scrum e os modelos tradicionais de gerenciamento de
projetos.

Modelo Tradicional de
Scrum
Gerenciamento de Projetos
A nfase est nas (nos) Pessoal Processos
Documentao Mnimaapenas se for exigido Exaustiva
Estilo de processos Iterativo Linear
Planejamento antecipado Baixo Alto
Com base no valor de negcio e
Priorizao de requisitos Fixo no Plano de Projeto
atualizado regularmente
Garantia de qualidade Centrada no cliente Centrada no processo
Organizao Auto-organizada Gerenciada
Estilo de gerenciamento Descentralizado Centralizado
Atualizaes no Backlog Sistema formal de
Mudana
Priorizado do Produto Gerenciamento da Mudana
Liderana Colaborativa, liderana servidora Comando e controle
Conformidade em relao ao
A medio do desempenho Valor do negcio
plano
Retorno sobre o investimento No Incio e durante projeto Final do projeto
Varia de acordo com o ciclo de
Participao do cliente Alta durante todo o projeto
vida do projeto

Tabela 1-2: Scrum x O Modelo Tradicional de Gerenciamento de Projetos

20 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

2. PRINCPIOS

2.1 Introduo
2
Os princpios do Scrum so a base sobre a qual o framework Scrum baseado, podem ser aplicados em
qualquer tipo de projeto ou organizao, e devem ser respeitados, a fim de assegurar a aplicao adequada
do Scrum. Os aspectos e os processos do Scrum podem ser modificados para atender s exigncias do
projeto, ou da organizao, mas os princpios do Scrum so inegociveis e devem ser aplicados conforme
descrito no framework apresentado em Um Guia para o Conhecimento em Scrum (Guia SBOK).
Mantendo os princpios framework Scrum intactos e usando-os de forma adequada, inspira-se confiana
para o usurio com relao realizao dos objetivos do projeto. Os princpios so considerados as
diretrizes fundamentais na aplicao do framework Scrum.

Os Princpios, conforme definido no Guia SBOK, so aplicveis a:

Portflios, programas, e/ou projetos em qualquer indstria


Produtos, servios ou outros resultados a serem entregues aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Este captulo est dividido nas seguintes sees:

2.2 Guia de PapisEsta seo descreve qual seo ou subseo mais relevante para cada um dos
papis centrais do Scrum: Dono do Produto, Scrum Master e Time Scrum.

2.3 Controle de Processos EmpricosEsta seo descreve o primeiro princpio do Scrum, e as trs
ideias principais de transparncia, inspeo e adaptao.

2.4 Auto-organizaoEsta seo destaca o segundo princpio do Scrum, que est focado nos
colaboradores atuais de uma organizao, que so motivados a compartilhar responsabilidades e acabam
agregando um valor maior ao seu trabalhao quando so expostos a um sistema de auto-organizao, o que
acaba gerando um ambiente mais criativo e innovador, mais propcio ao crescimento.

2.5 ColaboraoEsta seo enfatiza o terceiro princpio do Scrum, onde o desenvolvimento de produtos
um processo de criao de valor compartilhado que precisa de todos os Stakeholders, trabalhando e
interagindo em conjunto para garantir o maior valor. Tambm enfoca as dimenses fundamentais do
trabalho colaborativo: conscincia, articulao e apropriao.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 21


2 PRINCPIOS

2.6 Priorizao Baseada em ValorEsta seo apresenta o quarto princpio do Scrum, que destaca a
inteno do framework Scrum em entregar o mximo de valor de negcio em um perodo de tempo mnimo.

2.7 Time-boxingEsta seo explica o quinto princpio do Scrum que trata o tempo como uma restrio
limitante. Abrange tambm o Sprint, a Reunio Diria, e todas as outras reunies relacionadas ao Sprint,
como, Reunio de Planejamento do Sprint e Reunio de Reviso do Sprint. Todas essas reunies so
Time-boxed.

2.8 Desenvolvimento IterativoEsta seo aborda o sexto princpio do Scrum, que enfatiza que o
desenvolvimento iterativo ajuda a gerenciar melhor as mudanas e construir produtos que satisfaam as
necessidades dos clientes.

2.9 Scrum x O Modelo Tradicional de Gerenciamento de ProjetosEsta seo destaca as principais


diferenas entre os princpios do Scrum e os princpios do modelo tradicional de gerenciamento de projetos
(Modelo Cascata ou Waterfall), e explica como o Scrum funciona melhor no mundo atual em que mudanas
constantes ocorrem a todo o momento.

2.2 Guia de Papis

Todas as sees deste captulo so importantes para os Papis do Time Central do Scrum (Dono do
Produto, Scrum Master, e Time Scrum). Para fazer do framework Scrum um sucesso em qualquer
organizao, essencial um entendimento claro dos princpios do Scrum por todos os Stakeholders.

2.3 Controle de Processos Empricos

Em Scrum, as decises so tomadas com base na observao e em experimentos, ao invs de no


planejamento inicial detalhado. O Controle de Processos Empricos se baseia em trs idias principais:
transparncia, inspeo e adaptao.

2.3.1 Transparncia

A transparncia permite que todos os ngulos de qualquer processo Scrum sejam observados por qualquer
pessoa. Isto promove um fluxo de informao fcil e transparente em toda a organizao e cria uma cultura
de trabalho aberta. Em Scrum, a transparncia representada atravs de:

Uma Declarao da Viso do Projeto que pode ser vista por todos os stakeholders e pelo Time
Scrum.
Um Backlog Priorizado do Produto aberto, com Estrias de Usurio priorizadas que podem ser
vistas por todos, dentro e fora do Time Scrum.

22 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

Um Cronograma de Planejamento da Release que pode ser coordenado por vriosTimes Scrum.
Clara visibilidade sobre o progresso dos times atravs do uso de um Scrumboard, Grfico
Burndown e outras fontes de informao.
Reunies Dirias realizadas durante o processo de Conduzir a Reunio Diria, onde todos os
membros do time informam o que eles fizeram no dia anterior, o que eles planejam fazer no dia de
hoje e qualquer problema que os impea de concluir as suas tarefas no Sprint atual.
2
Reunies de Reviso do Sprint realizadas durante o processo de Demonstrar e Validar o Sprint,
em que o Time Scrum demonstra ao Dono do Produto e aos Stakeholders os potenciais
Entregveis do Sprint.

A figura 2-1 resume o conceito de transparncia em Scrum.

Figura 2-1: Transparncia em Scrum

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 23


2 PRINCPIOS

2.3.2 Inspeo

A Inspeo em Scrum representada atravs das seguientes aes:

Uso de um Scrumboard comum e de outras fontes de informao que mostrem o progresso do


Time Scrum em completar as tarefas do Sprint atual.
Coleta de feedback dos clientes e de outros stakeholers durante os processos de Desenvolver os
picos, Criar o Backlog Priorizado do Produto e Conduzir o Planejamento da Release.
Inspeo e aprovao das entregas, feitas pelo Dono do Produto e pelo cliente no processo de
Demonstrar e Validar o Sprint.

A figura 2-2 resume o conceito de inspeo em Scrum.

Figura 2-2: Inspeo em Scrum

2.3.3 Adaptao

A adaptao acontece quando o Time Central do Scrum e os Stakeholders aprendem atravs da


transparncia e da inspeo e, em seguida, adaptam o processo ao fazerem melhorias no trabalho que est
sendo realizado. Alguns exemplos de adaptao incluem:

A Reunio Diria, nesta reunio os membros do Time Scrum discutem abertamente sobre
impedimentos para completar suas tarefas e procuram a ajuda de outros membros do time. Os
Membros mais experientes do Time Scrum tambm orientam aqueles com menos conhecimento
sobre o projeto ou tecnologia.
A identificao de riscos que realizada e repetida ao longo do projeto. Os riscos identificados se
tornam entradas para vrios processos do Scrum, incluindo Criar o Backlog Priorizado do Produto,
Refinamento do Backlog do Produto, e Demonstrar e Validar o Sprint.

24 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

As melhorias que tambm podem resultar em Solicitaes de Mudana, que so discutidas e


aprovadas durante os processos de Desenvolver os picos, Criar o Backlog Priorizado do Produto
e Refinamento do Backlog do Produto.
O Scrum Guidance Body que interage com os membros do Time Scrum durante os processos de
Criar Estria de Usurio, Estimar as Taefas, Criar os Entregveis e o Refinamento do Backlog do
Produto, para oferecer orientao e tambm fornecer conhecimentos, conforme exigido.
2
O processo de Retrospectiva do Sprint, onde so determinados os Pontos de Melhoria Acordados
com base nas sadas do processo de Demonstrar e Validar o Sprint.
A Reunio de Retrospectiva do Projeto, durante est reunio os participantes documentam as
lies aprendidas e realizam revises, procura de oportunidades para melhorar os processos e
para ressaltar e discutir ineficincias ocorridas durante o processo.

A figura 2-3 resume o conceito de adaptao em Scrum.

Figura 2-3: Adaptao em Scrum

Em outros mtodos, comon o modelo tradicional Waterfall, requere-se que um planejamento considervel
seja feito com antecedncia e muitas vezes o cliente no rev os componentes do produto antes do final de
uma fase, ou do fim do projeto. Este mtodo geralmente apresenta grandes riscos para o sucesso do
projeto, j que tem um grande potencial em impactar significativamente na entrega do projeto e em sua

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 25


2 PRINCPIOS

aceitao pelo cliente. A interpretao e compreenso do cliente sobre o produto final pode ser muito
diferente do que foi realmente entendido e produzido pelo time, e isso pode ser percebido tarde demais.

A figura 2-4 demonstra um exemplo desses desafios.

Figura 2-4: Desafios do Gerenceiamento de Projetos no Modelo Tradicional

26 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

2.4 Auto-organizao
O Scrum acredita que os colaboradores so auto-motivados e procuram aceitar responsabilidades maiores.
Com isso, eles entregam um valor maior quando auto-organizados.

O estilo de liderana preferido em Scrum a "liderana servidora", que enfatiza a obteno de resultados,
focando nas necessidades do Time Scrum. Consulte a seo 3.10.3 para mais informaes sobre os vrios 2
estilos de liderana e de gerenciamento.

2.4.1 Benefcios da Auto-organizao

A auto-organizao como um princpio essencial em Scrum leva ao seguinte:

Time buy-in e responsabilidade compartilhada


Motivao, o que resulta em um nvel melhor de desempenho do time
Ambiente inovador e criativo favorvel ao crescimento

A auto-organizao no significa que os membros do time estejam autorizados a agir da maneira que eles
quiserem. Significa apenas que, uma vez que a Viso do Produto definida no processo de Criar a Viso
do Projeto, o Dono do Produto, o Scrum Master e o Time Scrum so identificados. Alm disso, o Time
Central do Scrum trabalha diretamente com o(s) Stakeholder(s) relevante(s), para aperfeioar os requisitos
enquanto os mesmos passam pelos processos de Desenvolver os picos e Criar as Estrias de Usurio. A
experincia do time utilizada para avaliar as entradas necessrias para executar o trabalho planejado
para o projeto. Esse julgamento e experincia so aplicados a todos os aspectos tcnicos e de
gerenciamento do projeto durante o processo de Criar os Entregveis.

Apesar da priorizao ser feita principalmente pelo Dono do Produto, que representa a voz do cliente, o
Time Scrum auto-organizado est envolvido na distribuio e estimativa de tarefas durante os processos de
Criar as Tarefas e de Estimar as Tarefas. Durante esses processos, cada membro do time responsvel
por determinar o trabalho que ele ou ela ir realizar. Durante a execuo de um Sprint, se os membros do
time precisarem de ajuda para completar suas tarefas, o Scrum abordar este assunto na Reunio Diria,
uma interao regular e obrigatria. O prprio Time Scrum interage com outros times atravs das Reunies
do Scrum de Scrums (SoS), e pode procurar orientao adicional se necessrio, no Scrum Guidance Body.

Por fim, o Time Scrum e o Scrum Master trabalham juntos para demonstrar o incremento do produto criado
durante o processo de Demonstrar e Validar o Sprint, onde as entregas devidamente concludas sero
aceitas. Uma vez que as entregas sejam potencialmente utilizveis, (e o Backlog Priorizado do Produto seja
priorizado pelas Estrias de Usurio na ordem de valor em que foram criadas), o Dono do Produto e o
cliente podem visualizar e articular o valor que est sendo criado aps cada Sprint; e o Time Scrum por sua
vez, tem a satisfao de ver o seu trabalho ser aceito pelo cliente e pelos Stakeholders.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 27


2 PRINCPIOS

Os principais objetivos de times auto-organizados so:

Compreender a Viso do Projeto, e por que o projeto agrega valor organizao


Estimar Estrias de Usurio durante o processo de Aprovar, Estimar e Comprometer as Estrias de
Usurio, e atribuir tarefas a si mesmos durante o processo de Criar o Backlog do Sprint
Criar tarefas de forma independente durante o processo de Criar as Tarefas
Aplicar e aprimorar os seus conhecimentos por ser um time multifuncional, para trabalhar nas
tarefas durante o processo de Criar Entregveis
Entregar resultados tangveis que so aceitos pelo cliente e pelos stakeholders durante o processo
de Demonstrar e Validar o Sprint
Resolver em conjunto problemas individuais abordados durante as Reunies Dirias
Esclarecer quaisquer discrepncias ou dvidas e estar aberto para aprender coisas novas
Atualizar o conhecimento e a habilidade de forma contnua por meio de interaes regulares do
time
Manter a estabilidade dos membros do time durante toda a durao do projeto, no alterando os
membros, a menos que seja inevitvel

A figura 2-5 ilustra os objetivos de um time auto-organizado.

Figura 2-5: Objetivos de um time auto-organizado

28 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

2.5 Colaborao
A Colaborao em Scrum refere-se ao Time Central do Scrum trabalhando e interagindo em conjunto com
os Stakeholders para criar e validar as entregas do projeto, para assim atingir os objetivos delineados na
Viso do Projeto. importante notar a diferena entre cooperao e colaborao. A Cooperao ocorre
quando o produto do trabalho consiste na soma dos esforos de trabalho de vrias pessoas em um time. A 2
Colaborao ocorre quando um time trabalha em conjunto, contribuindo uns com os outros para produzir
algo maior.

As dimenses principais do trabalho colaborativo so:

ConscinciaOs indivduos que trabalham juntos precisam estar cientes do trabalho um do outro.
ArticulaoOs colaboradores devem dividir o trabalho em unidades, dividir as unidades entre os
membros do time, e em seguida, assim que o trabalho for concludo, devem reintegr-lo.
ApropriaoAdaptao de tecnologia para a prpria situao; a tecnologia pode ser usada de
uma maneira completamente diferente do que esperado pelos designers.

2.5.1 Benefcios da Colaborao em Projetos Scrum

O Manifesto gil (Fowler e Highsmith, 2001) enfatiza a "colaborao do cliente acima da negociao de
contrato." Assim, o framework Scrum adota uma abordagem em que os membros do Time Central do
Scrum (Dono do Produto, Scrum Master e Time Scrum), colaboraram uns com os outros e com os
Stakeholders para criar os entregveis que proporcionem o maior valor possvel para o cliente. Essa
colaborao ocorre durante todo o projeto.

A colaborao garante que os seguintes benefcios do projeto sejam realizados:

1. A necessidade de mudanas devido a requisitos mal esclarecidos so minimizadas. Por exemplo,


durante os processos de Criar a Viso do Projeto, Desenvolver os picos, e Criar o Backlog
Priorizado do Produto, o Dono do Produto colabora com os stakeholders para respectivamente
criar a Viso do Projeto, os picos e o Backlog Priorizado do Produto. O que garante um
entendimento claro entre os membros Time Central do Scrum sobre o trabalho que ser necessrio
para a concluso do projeto. O Time Scrum colabora continuamente com o Dono do Produto e com
os stakeholders atravs de um Backlog Priorizado do Produto transparente, para criar os
entregveis do projeto. Os processos de Conduzir a Reunio Diria, de Refinamento do Backlog
Priorizado do Produto, e de Retrospectiva do Sprint oferecem aos membros do Time Central do
Scrum a possibilidade de discutir o que foi feito, e de colaborar com o que precisa ser feito. Assim,
o nmero de Solicitaes de Mudana feitas pelo cliente, e o retrabalho so minimizados.

2. Os riscos so identificados e tratados de forma eficiente. Por exemplo, os riscos para o projeto so
identificados e avaliados pelos membros do Time Central do Scrum durante os processos de
Desenvolver os picos, Criar os Entregveis, e Conduzir a Reunio Diria. As ferramentas de

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 29


2 PRINCPIOS

reunies do Scrum, como o Reunio Diria, Reunio de Planejamento do Sprint, Reunio de


Reviso do Backlog Priorizado do Produto, e assim por diante, proporcionam oportunidades para o
time, no apenas de identificar e avaliar os riscos, mas tambm para implementar respostas aos
riscos, para os riscos de alta prioridade.

3. O verdadeiro potencial do time realizado. Por exemplo, o processo de Conduzir a Reunio Diria
fornece a possibilidade do Time Scrum de colaborar e entender os pontos fortes e fracos de seus
membros. Se um membro do time perder o prazo de entrega de uma tarefa, os membros do Time
Scrum se organizam de forma colaborativa para completar a tarefa e cumprir as metas acordadas
para a concluso do Sprint.

4. A melhoria contnua assegurada atravs de lies aprendidas. Por exemplo, o Time Scrum utiliza
o processo de Retrospectiva do Sprint para identificar o que ocorreu bem, ou no, durante o Sprint
anterior. Isso oferece ao Scrum Master a oportunidade de trabalhar no aperfeioamento do time,
reformulando e melhorando os processos para o prximo Sprint. Isso tambm ir garantir que a
colaborao seja ainda mais eficaz no prximo Sprint.

A figura 2-6 ilustra os benefcios da colaborao em projetos Scrum.

Figura 2-6: Benefcios da Colaborao em Projetos Scrum

30 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

2.5.2 Importncia da Colocation em Colaborao

Em muitas das prticas do Scrum, uma comunicao de alta frequencia necessria. Para que isso seja
possvel, prefere-se que os membros do time estejam localizados no mesmo ambiente. O que permite tanto
a interao formal, quanto a informal entre os membros do time. Proporcionando a vantagem em ter todos
os membros do time sempre mo, para a coordenao, resoluo de problemas e aprendizagem. Alguns
2
dos benefcios de colocation so os seguintes:

Perguntas so respondidas rapidamente.


Problemas acontecem no local.
Ocorre menos atrito entre as interaes.
A confiana adquirida e recompensada com muito mais rapidez.

As ferramentas de colaborao que podem ser usadas para os times que trabalham em colocation ou
distribudos so:

1. Times em Colocation (ou seja, os times que trabalham no mesmo escritrio)Em Scrum,
prefervel ter os times em colocation. Sendo assim, os mtodos preferidos de comunicao
incluem; interaes cara-a-cara, Salas de Decises (ou War Room), Scrumboards, monitores de
parede, mesas compartilhadas, e assim por diante.

2. Times Distribudos (ou seja, os times que trabalham em locais fsicos diferentes)Embora seja
prefervel que os times trabalhem em colocation, s vezes, o Time Scrum pode trabalhar de acordo
com o modelo distribudo, devido terceirizao, offshoring, diferentes locais fsicos, opes de
home office, etc. Algumas ferramentas que podem ser usadas para uma colaborao eficaz entre
os times distribudos incluem: videoconferncia, mensagens instantneas, chats, mdias sociais,
telas compartilhadas e ferramentas de software que simulam a funcionalidade do Scrumboards,
monitores de parede e assim por diante.

2.6 Priorizao baseada em valor


O framework Scrum impulsionado pelo objetivo de oferecer o mximo valor de negcio em um perodo de
tempo mnimo. Uma das ferramentas mais eficazes para realizar esse objetivo a priorizao.

A Priorizao pode ser definida como a determinao da ordem e da separao do que deve ser feito
agora, a partir do que precisa ser feito mais tarde. O conceito de priorizao no novidade em
gerenciamento de projetos. O modelo tradicional de gerenciamento de projetos (Waterfall), prope a
utilizao de vrias ferramentas de priorizao de tarefas. Do ponto de vista do Gerente do Projeto, a
priorizao fundamental, j que certas tarefas devem ser realizadas primeiro para agilizar o processo de
desenvolvimento e alcanar os objetivos do projeto. Algumas das tcnicas tradicionais de priorizao de
tarefas, incluem os prazos de definio para tarefas delegadas e a utilizao de matrizes de priorizao.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 31


2 PRINCPIOS

O Scrum, no entanto, usa a Priorizao Baseada em Valor como um dos princpios fundamentais que
impulsiona a estrutura e funcionalidade de todo o framework Scrum, ajudando os projetos a se beneficiarem
atravs da adaptabilidade e desenvolvimento iterativo do produto ou servio. Mais significativamente, o
Scrum tem como objetivo, entregar um produto ou servio de valor para o cliente durante todas as fases do
projeto.

A Priorizao feita pelo Dono do Produto, quando ele ou ela prioriza as Estrias de Usurio no Backlog
Priorizado do Produto. O Backlog Priorizado do Produto contm uma lista de todos os requisitos
necessrios para a realizao do projeto.

Uma vez que o Dono do Produto recebe os requisitos de negcio do cliente, e transcreve para a forma de
Estrias de Usurio viveis, ele ou ela ento trabalha com o cliente e com o patrocinador para entender
quais so os requisitos de negcios que fornecem o maior valor de negcio. O Dono do Produto deve
entender o que o cliente quer e os valores, a fim de organizar os itens do Backlog Priorizado do Produto
(Estrias de Usurio) por importncia relativa. s vezes, o cliente pode exigir que todas as Estrias de
Usurio sejam de alta prioridade. Nesse caso, a prpria lista de alta prioridade de Estrias de Usurio deve
ser priorizada. A Priorizao de um backlog envolve determinao da importncia de cada Estria de
Usurio. Os requisitos de alto valor so identificados e movidos para o topo do Backlog Priorizado do
Produto. O princpio da Priorizao Baseada em Valor colocado em prtica durante os processos de Criar
o Backlog do Produto e o Refinamento do Backlog do Produto.

O Dono do Produto deve trabalhar simultaneamente, com o Time Scrum para entender os riscos e as
incertezas do projeto, pois podem haver consequncias negativas associadas a eles. Isso deve ser levado
em conta ao priorizar-se as Estrias de Usurio em uma abordagem baseada em valor (consulte o captulo
de Risco para mais informaes). O Time Scrum tambm alerta o Dono do Produto sobre quaisquer
dependncias que surjam na implementao. Estas dependncias devem serem levadas em conta durante
a priorizao. A priorizao pode ser baseada em uma estimativa subjetiva do valor de negcio projetado,
ou de sua rentabilidade, ou pode ainda basear-se em resultados e anlises de mercado, utilizando
ferramentas, incluindo mas no limitado-se a, entrevistas com clientes, pesquisas, modelos financeiros e
tcnicas de anlise.

O Dono do Produto tem que traduzir as entradas e as necessidades dos stakeholders, com relao ao
projeto, para criar o Backlog Priorizado do Produto. Assim, ao priorizar as Estrias de Usurio no Backlog
Priorizado do Produto, trs fatores so considerados (ver Figura 2-7):

1. Valor
2. Risco ou incerteza
3. Dependncias

Neste caso, a priorizao resulta em entregas que satisfazem os requisitos do cliente com o objetivo de
fornecer o maior valor de negcio no menor tempo possvel.

32 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

2
Figura 2-7: Priorizao Baseada em Valor

2.7 Time-boxing
O Scrum trata o tempo como uma das restries mais importantes no gerenciamento de um projeto. Para
solucionar as restries de tempo, o Scrum introduz um conceito chamadoTime-boxing, que prope a
fixao de um certo perodo de tempo para cada processo e atividade de um projeto Scrum. Isso garante
com que os membros do Scrum no usem muito tempo (ou pouco) em um trabalho especfico, e no
gastem o seu tempo e energia em um trabalho no qual eles tenham pouco conhecimento.

Algumas das vantagens de Time-boxing:

Processo de desenvolvimento eficiente


Reduo de despesas gerais
Alta velocidade para os times

O Time-boxing pode ser utilizado em muitos processos Scrum, por exemplo, no processo de Conduzir a
Reunio Diria, a durao da Reunio Diria Time-boxed. s vezes, o Time-boxing pode ser usado para
evitar a melhoria excessiva de um item (ou seja, gold-plating).

O Time-boxing uma prtica fundamental em Scrum e deve ser aplicado com cuidado. Sendo que se for
utilizado de forma arbitrria pode levar a desmotivao do time, tendo como consequncia a criao de um
ambiente apreensivo, por isso deve ser usado de forma adequada.

2.7.1 Scrum Time-boxes

SprintUm Sprint uma iteraoTime-boxed, de 1 a 6 semanas de durao, durante o qual o


Scrum Master guia, facilita e protege o Time Scrum de impedimentos internos e externos durante o
processo de Criar os Entregveis. Isso ajuda a evitar a distoro da viso, o que poderia afetar a
meta do Sprint. Durante esse tempo, o time trabalha para converter os requisitos do Backlog
Priorizado do Produto em funcionalidades dos produtos que podem ser entregues. Para obter o
mximo de benefcios a partir de um projeto Scrum, sempre recomendvel manter o Sprint Time-

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 33


2 PRINCPIOS

boxed em 4 semanas, a menos que existam projetos com requisitos muito estveis, onde os
Sprints podem se estender at 6 semanas.

Reunio Diria uma reunio diria curta, Time-boxed em 15 minutos. Os membros do time se
renem para relatar o andamento do projeto, respondendo s trs seguintes perguntas:

1. O que eu fiz ontem?


2. O que eu vou fazer hoje?
3. Que impedimentos ou obstculos (se houver) estou enfrentando atualmente?

Essa reunio realizada pelo time como parte do processo de Conduzir a Reunio Diria.

Reunio de Planejamento do SprintUma reunio realizada antes do Sprint, como parte do


processo de Criar o Backlog do Sprint. Para um Sprint de um ms Time-boxed em oito horas. A
Reunio de Planejamento do Sprint dividida em duas partes:

1. Definio do objetivoDurante a primeira metade da reunio, o Dono do Produto explica


para o Time Scrum, as prioridades mximas das Estrias de Usurio ou os requisitos do
Backlog Priorizado do Produto. O Time Scrum em colaborao com o Dono do Produto
ento define o objetivo do Sprint.

2. Estimativa de trabalhoDurante a segunda metade da reunio, o Time Scrum decide


"como" completar os itens seleccionados no Backlog Priorizado do Produto, para cumprir a
meta do Sprint.

s vezes, as Reunies de Planejamento de Tarefas (realizadas durante o processo de Criar as


Tarefas) e as Reunies de Estimativa de Tarefas (realizadas durante o processo de Estimar as
Tarefas) tambm so referidas como Reunies de Planejamento do Sprint.

Reunio de Reviso do SprintA Reunio de Reviso do Sprint Time-boxed em quatro horas


para um Sprint de um ms. Durante a Reunio de Reviso do Sprint, que realizada no processo
de Demonstrar e Validar o Sprint, o Time Scrum apresenta ao Dono do Produto os resultados do
Sprint atual. O Dono do Produto revisa e compara o produto (ou incremento do produto), com os
Critrios de Aceitao acordados, e aceita ou rejeita as Estrias de Usurio.

Reunio de Retrospectiva do SprintPara um Sprint de um ms, Time-boxed em quatro


horas, e realizada como parte do processo de Retrospectiva do Sprint. Durante esta reunio, o
Time Scrum se rene para analisar e refletir sobre o Sprint anterior, com relao aos processos
seguidos, ferramentas empregadas, mecanismos de colaborao e de comunicao e outros
aspectos relevantes para o projeto. O time discute sobre o que correu de forma positiva ou
negativa durante o Sprint anterior, o objetivo aprender e fazer melhorias nos prximos Sprints.

34 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

Algumas oportunidades de melhorias evidenciadas durante a reunio, tambm podem ser


atualizadas como parte dos documentos do Scrum Guidance Body.

A figura 2-8 ilustra as duraes Time-boxed para as reunies relacionadas com o Scrum.

Figura 2-8: Duraes Time-Box para Reunies do Scrum

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 35


2 PRINCPIOS

2.8 Desenvolvimento iterativo


O framework Scrum impulsionado pelo objetivo de oferecer o maior valor de negcio em um curto perodo
de tempo. Para alcanar este objetivo, na prtica, o Scrum acredita em desenvolvimento iterativo de
resultados.

Na maioria dos projetos complexos, o cliente pode no ser capaz de definir totalmente os requisitos, ou
ainda, no ter certeza de como deve ser o produto final. O modelo iterativo mais flexvel para assegurar
que qualquer mudana solicitada pelo cliente possa ser includa como parte do projeto. Possivelmente as
Estrias de Usurio sero escritas constantemente durante todo o perodo de durao do projeto. Nos
estgios iniciais da escrita, a maioria das Estrias de Usurio so funcionalidades de alto nvel. Essas
Estrias de Usurio so conhecidos como picos. Os picos, so geralmente muito grandes para serem
completados pelo time em apenas um Sprint. Portanto, so divididos em Estrias de Usurio menores.

Cada aspecto complexo do projeto dividido atravs da elaborao progressiva durante o processo de
Refinamento do Backlog Priorizado do Produto. Os processos de Criar as Estrias de Usurio e Aprovar,
Estimar e Comprometer as Estrias de Usurio so usados para adicionar novos requisitos ao Backlog
Priorizado do Produto. A tarefa do Dono do Produto garantir o aumento do Retorno sobre Investimento,
concentrando-se no valor e em sua entrega contnua durante cada Sprint. Quando o Dono do Produto
elabora o Backlog Priorizado do Produto ele deve ter um bom entendimento sobre a justificativa de negcio
do projeto e do valor que o projeto deve supostamente entregar, e assim, decidir quais resultados e,
consequentemente, quais valores sero entregues em cada Sprint. Em seguida, os processos de Criar as
Tarefas, Estimar as Tarefas, e Criar o Backlog do Sprint produzem o Backlog do Sprint, o qual utilizado
pelo time para criar os entregveis.

Em cada Sprint, o processo de Criar os Entregveis usado para desenvolver as sadas do Sprint. O
Scrum Master tem que garantir que os processos do Scrum sejam seguidos, e deve ainda auxiliar o time,
para que o mesmo trabalhe da maneira mais produtiva possvel. O Time Scrum se auto-organiza e tem
como objetivo criar os Entregveis do Sprint a partir das Estrias de Usurio no Backlog do Sprint. Em
grandes projetos, vrios times multifuncionais trabalham em paralelo durante o Sprints, oferecendo
solues potencialmente utilizveis no final de cada Sprint. Uma vez que o Sprint seja concludo, o Dono do
Produto aceita ou rejeita os entregveis com base nos Critrios de Aceitao do processo de Demonstrar e
Validar o Sprint.

Como ilustrado na figura 2-9, os projetos Scrum so concludos de forma iterativa entregando valor ao
longo do seu ciclo de vida.

36 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


2 PRINCPIOS

Figura 2-9: Scrum x O Modelo Tradicional Cascata (Waterfall)

O benefcio do desenvolvimento iterativo que ele permite a correo de curso, na medida em que todas
as pessoas envolvidas adquirem um melhor entendimento sobre o que precisa ser entregue como parte do
projeto, e incorporando esse conhecimento de maneira iterativa. Assim, o tempo e o esforo necessrio
para chegar ao ponto final consideravelmente reduzido e o time produz resultados que so mais
adequados ao ambiente de negcios.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 37


2 PRINCPIOS

2.9 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


A nfase do modelo tradicional de gerenciamneto de projetos est na realizao do planejamento inicial do
projeto, com nfase na fixao do escopo, custo e cronograma, e gerenciamento desses parmetros. O
modelo tradicional de gerenciamento de projetos pode muitas vezes levar a uma situao em que, embora
o plano tenha sido bem sucedido, o cliente no est satisfeito.

O framework Scrum baseia-se na crena de que os colaboradores de hoje tem muito mais a oferecer do
que apenas seus conhecimentos tcnicos, e de que a ideia de mapeamento e planejamento no eficiente
em um ambiente de constante mudanas. Portanto, o Scrum incentiva a tomada de decises iterativa,
baseada em dados. Em Scrum, o foco principal a entrega de produtos que satisfaam as necessidades
dos clientes, em pequenos incrementos iterativos que sejam utilizveis.

Para entregar a maior quantidade de valor no menor tempo possvel, o Scrum promove a priorizao e
Time-boxing sobre a fixao do escopo, custo e cronograma de um projeto. Uma caracterstica importante
do Scrum a auto-organizao, permitindo que as pessoas que esto realmente fazendo o trabalho,
estimem e se responsabilizem pelas tarefas.

38 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3. ORGANIZAO

3.1 Introduo
Nesta seo, iremos discutir os vrios ngulos de uma organizao do projeto Scrum, bem como os papis
centrais e no-essenciais, e como formar os Times Scrum de alto desempenho. 3
Organizao, tal como definido em Um Guia para o Conhecimento em Scrum (Guia SBOK), aplicvel ao
seguinte:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou qualquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O Scrum
pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos pequenos com
um time de apenas seis membros ou mais, como tambm em projetos grandes e complexos, com centenas
de membros por time.

Este captulo est dividido nas seguintes sees:

3.2 Guia de PapisEsta seo identifica qual seo ou subseo importante para um Dono do Produto,
Scrum Master e Time Scrum.

3.3 Papis do Projeto ScrumEsta seo abrange todos os papis centrais e no-essenciais, associados
um projeto Scrum.

3.4 Dono do ProdutoEsta seo destaca as principais responsabilidades do Dono do Produto em relao
a um projeto Scrum.

3.5 Scrum MasterEsta seo enfoca as principais responsabilidades do Scrum Master, no contexto de um
projeto Scrum.

3.6 Time ScrumEsta seo destaca as principais responsabilidades do Time Scrum no contexto de um
projeto Scrum.

3.7 Scrum em Projetos, Programas, and PortfliosEsta seo se concentra em como o framework
Scrum pode ser adaptado e utilizado em diferentes contextos de programas e portflios. Tambm destaca as
responsabilidades especficas dos membros do Time Scrum em relao comunicao, integrao e ao
trabalho com os times de gerenciamento corporativo e de programa.

3.8 ResponsabilidadesEsta seo descreve as responsabilidades relevantes ao tema da Organizao,


para todos os membros que trabalham em um projeto, com base em seus papis.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 39


3 ORGANIZAO

3.9 Scrum x O Modelo Tradicional de Gerenciamento de ProjetosEsta seo explica as diferenas e as


principais vantagens do modelo Scrum em relao ao modelo tradicional de gerenciamento de projetos
(Waterfall/Cascata).

3.10 Teorias Populares de RH e suas Relevncias para o ScrumEsta seo contm algumas das
teorias mais populares de RH, teis para todos os membros do Time Central do Scrum.

3.2 Guia de Papis


1. Dono do Produto imperativo para o Dono do Produto ler todo este captulo.

2. Scrum MasterO Scrum Master tambm deve estar familiarizado com este captulo inteiro, com foco
principal nas sees 3.3, 3.5, 3.6, 3.8 e 3.10.4.

3. Time ScrumO time Scrum deve se concentrar principalmente nas seces 3.3, 3.6 e 3.8.

3.3 Papis do Projeto Scrum


muito importante entender os papis e as responsabilidades definidas para garantir o sucesso da
implementao dos projetos Scrum.

Os Papis do Scrum dividem-se em duas categorias:

1. Papis Centraisso aqueles papis que so obrigatoriamente necessrios para produzir o


produto do projeto, esto comprometidos com o projeto e, finalmente, so responsveis pelo
sucesso de cada Sprint e do projeto como um todo.

2. Papis no-essenciaisso aqueles papis que no so obrigatoriamente necessrios para o


projeto Scrum, e podem incluir membros do time que esto interessados no projeto, que no tm
nenhum papel formal no time do projeto, que podem interagir com o time, mas que no podem ser
responsveis pelo sucesso do projeto. Os papis no-essenciais tambm devem ser levados em
considerao em qualquer projeto Scrum.

40 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.3.1 Papis Centrais

Existem trs papis principais em Scrum que so em ltima instncia responsveis pelo cumprimento dos
objetivos do projeto. Os papis principais so: Dono do Produto, Scrum Master e Time Scrum. Juntos, so
referidos como Time Central do Scrum. importante notar que, destes trs papis, nenhum papel tem
autoridade sobre o outro.

1. Dono do Produto
3
O Dono do Produto a pessoa responsvel por maximizar o valor do negcio para o projeto. Ele ou
ela responsvel por articular as necessidades dos clientes e manter a justificativa de negcio para
o projeto. O Dono do Produto representa a Voz do Cliente.

Correspondente ao papel de Dono do Produto em um projeto, pode haver um Dono do Produto do


Programa (para um programa) ou um Dono do Produto do Portflio (para um portflio).

2. Scrum Master

O Scrum Master um facilitador, que garante ao Time Scrum o fornecimento de um ambiente


propcio para concluir com sucesso o projeto. O Scrum Master guia, facilita e ensina as prticas do
Scrum para todos os envolvidos no projeto; remove os impedimentos encontrados pelo time; e,
assegura que os processos do Scrum estejam sendo seguidos.

Observe que o papel de Scrum Master muito diferente do papel desempenhado pelo Gerente de
Projeto em um modelo tradicional de gerenciamento de projetos (em cascata/waterfall), em que o
gerente de projeto trabalha como um gerente ou lder para o projeto. O Scrum Master, no entanto,
trabalha como um facilitador, ele ou ela est no mesmo nvel hierrquico que outros membros do
Time Scrum - qualquer membro do Time Scrum que tenha a habilidade de facilitar projetos Scrum,
pode se tornar o Scrum Master de um projeto ou Sprint.

Correspondente ao papel de Scrum Master em um projeto, pode haver um Scrum Master do


Programa (para um programa) ou um Scrum Master do Portflio (para um portflio).

3. Time Scrum

O Time Scrum um grupo ou um time de pessoas que so responsveis por entender os requisitos
de negcio especificados pelo Dono do Produto, estimar Estrias de Usurio e criar os entregveis
finais do projeto.

A figura 3-1 apresenta uma viso geral dos papis do Time Central do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 41


3 ORGANIZAO

Figura 3-1: Viso Geral dos Papis do Scrum

3.3.2 Papis No-Essenciais

Os papis no-essenciais so aqueles papis que no so obrigatoriamente necessrios para o projeto


Scrum e podem no estar continuamente ou diretamente envolvidos no processo Scrum. No entanto,
importante ter conhecimento sobre os papis no-essenciais, pois eles podem desempenhar um papel
significativo em alguns projetos Scrum.

Os Papis no-essenciais podem incluir o seguinte:

1. Stakeholder(s)

Stakeholder(s) um termo coletivo que inclui clientes, usurios e patrocinadores, que interagem
frequentemente com o Dono do Produto, com o Scrum Master e com o Time Scrum fornecendo
entradas e facilitando a criao de produtos, servios ou outro resultado do projeto. Os stakeholders
influenciam o projeto ao longo de seu desenvolvimento, e podem tambm ter um papel a ser
desempenhado durante os processos de Desenvolver os picos, Criar o Backlog Priorizado do
Produto, Conduzir o Planejamento da Release, Retrospectiva do Sprint, entre outros.

Cliente

O cliente o indivduo ou a organizao que adquire o produto, servio, ou outro resultado do


projeto. Para qualquer organizao, dependendo do projeto, podem haver clientes internos
(dentro da mesma organizao) ou clientes externos (fora da organizao).

42 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

Usurios

Os usurios so os indivduos ou a organizao que utiliza diretamente o produto, servio, ou


outro resultado do projeto. Como em clientes, para qualquer organizao, podem haver usurios
internos e externos. Alm disso, em algumas indstrias clientes e usurios podem ser os
mesmos.

Patrocinador
3
O patrocinador o indivduo ou a organizao que fornece recursos e apoio para o projeto. O
patrocinador tambm o stakeholder.

s vezes, a mesma pessoa ou organizao pode desempenhar mltiplos papis de stakeholder; por
exemplo, o patrocinador e o cliente podem ser o mesmo.

2. Fornecedores

Fornecedores incluem indivduos externos ou organizaes que fornecem produtos e servios, que
no esto dentro das competncias essenciais da organizao do projeto.

3. Scrum Guidance Body

O Scrum Guidance Body (SGB) um papel opcional. Geralmente consiste de um conjunto de


documentos e/ou um grupo de especialistas que esto geralmente envolvidos na definio de
objetivos relacionados com a qualidade, regulamentaes governamentais, de segurana e outros
parmetros-chave da organizao. Estes objetivos orientam o trabalho realizado pelo Dono do
Produto, Scrum Master e Time Scrum. O Scrum Guidance Body tambm ajuda a capturar as
melhores prticas que devem ser usadas na organizao, em todos os projetos Scrum.

O Scrum Guidance Body no toma decises relacionadas ao projeto. Em vez disso, atua como uma
consultoria ou estrutura de orientao para todos os nveis de hierarquia da organizao do projeto;
no portflio, programa e projeto. Os Times Scrum tem a opo de pedir conselho ao Scrum
Guidance Body, conforme exigido.

3.4 Dono do Produto


O Dono do Produto representa os interesses da comunidade de stakeholders para o Time Scrum. O Dono do
Produto responsvel por garantir uma comunicao clara para o Time Scrum, sobre requisitos de
funcionalidade do produto ou servio, definindo os Critrios de Aceitao, e garantindo o cumprimento desses
critrios. Em outras palavras, o Dono do Produto responsvel por garantir que o Time Scrum entregue
valor. O Dono do Produto deve sempre manter uma viso dupla. Ele ou ela deve compreender e apoiar as
necessidades de todos os stakeholders, ao mesmo tempo, compreender as necessidades e a forma de

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 43


3 ORGANIZAO

trabalho do Time Scrum. Como o Dono do Produto deve entender as necessidades e prioridades dos
stakeholders, incluindo clientes e usurios, esse papel comumente referido como a Voz do Cliente.

A tabela 3-1 resume as responsabilidades do Dono do Produto nos vrios processos Scrum.
Processos As Responsabilidades do Dono do Produto
Definir a Viso do Projeto
8.1 Criar a Viso do Projeto
Ajudar a Criar a Patente do Projeto e Oramento do Projeto
8.2 Identificar Scrum Master e Ajudar a finalizar o Scrum Master para o projeto
o(s)Stakeholder(s) Identificar Stakeholder(s)
Ajudar a determinar os membros do Time Scrum
8.3 Formar o Time Scrum Ajudar a desenvolver um Plano de Colaborao
Ajudar a desenvolver o Plano de Team Building com o(s) Scrum Master(s)
8.4 Desenvolver o(s) pico(s) Criar os pico(s) e Personas
8.5 Criar o Backlog Priorizado Priorizar os Itens do Backlog Priorizado do Produto
do Produto Definir o Critrio de Pronto
8.6 Conduzir o Planejamento Criar o Cronograma de Planejamento da Release
da Release Ajudar a determinar a Durao do Sprint
9.1 Criar as Estrias de Ajudar a criar as Estrias de Usurio
Usurio Definir os Critrios de Aceitao para cada Estria de Usurio
9.2 Aprovar, Estimar e
Aprovar as Estrias de Usurio
Compromoter as Estrias
Facilitar o Time Scrum a comprometer as Estrias de Usurio
de Usurio
Explicar as Estrias de Usurio para o Time Scrum, enquanto cria a lista de
9.3 Criar as Tarefas
tarefas
Fornecer orientaes e esclarecimentos para o Time Scrum na estimativa de
9.4 Estimar as Tarefas
esforo para as tarefas
9.5 Criar o Backlog do Sprint Esclarecer os requisitos para o Time Scrum, enquanto cria o Backlog do Sprint
10.1 Criar os Entregveis Esclarecer os requisitos de negcios para o Time Scrum
10.3 Refinamento do Backlog
Refinar o Backlog Priorizado do Produto
Priorizado do Produto
Aceitar/Rejeitar os Entregveis
11.2 Demonstrar e Validar os
Fornecer o feedback necessrio para o Scrum Master e para os Times Scrum
Sprints
Atualizar o Plano da Release no Backlog Priorozado do Produto
12.1 Envio de Entregveis Ajudar a implantar a Release de Produtos, coordenao feita com o cliente
12.2 Retrospectiva do Projeto Participar de Reunies de Retrospectiva do Sprint

Tabela 3-1: Responsabilidade do Dono do Produto em Processos Scrum

44 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

Outras responsabilidades do Dono do Produto:

Determinar os requisitos gerais iniciais do projeto e dar incio s suas atividades; isso pode envolver
a interao com o Dono do Produto do Programa e com o Dono do Produto do Portflio, para
garantir que o projeto esteja alinhado de acordo com a orientao dada pela alta administrao.
Representar o(s) usurio(s) do produto ou servio com um profundo conhecimento sobre a
comunidade dos usurios.
Garantir os recursos financeiros iniciais e em andamento para o projeto.
3
Focar na criao de valor, e de forma geral, no Retorno sobre Investimento.
Avaliar a viabilidade e garantir a entrega do produto ou servio.

3.4.1 Voz do Cliente (VOC)

Como representante do cliente, o Dono do Produto referido como sendo a voz do cliente, j que ele garante
que as necessidades explcitas e implcitas do cliente sejam traduzidas em Estrias de Usurio no Backlog
Priorizado do Produto e, posteriormente, utilizadas na criao dos Entregveis do projeto para o cliente.

3.4.2 Dono do Produto Chefe

No caso de grandes projetos com inmeros Times Scrum, ter um Dono do Produto Chefe pode ser uma
necessidade. Este papel responsvel pela coordenao do trabalho de vrios Donos do Produto. O Dono
do Produto Chefe prepara e mantm todo o Backlog Priorizado do Produto para o projeto, coordenando o
trabalho entre os Donos do Produto dos Times Scrum. Os Donos do Produto, por sua vez, gerenciam suas
respectivas partes no Backlog Priorizado do Produto.

O Dono do Produto Chefe tambm interage com o Dono do Produto do Programa para garantir o alinhamento
de grandes projetos, com as metas e objetivos do programa.

3.5 Scrum Master


O Scrum Master o "lder servidor" do Time Scrum, aquele que modera e facilita a interao do time, agindo
como motivador e mentor do time. O Scrum Master responsvel por garantir que o time tenha um ambiente
de trabalho produtivo, protegendo o time de influncias externas, removendo qualquer impedimento, e
aplicando os princpios, aspectos e processos do Scrum.

A tabela 3-2 resume as responsabilidades do Scrum Master nos vrios processos Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 45


3 ORGANIZAO

Processos Responsabilidades do Scrum Master


8.2 Identificar o Scrum Master e
Ajudar a identificar o(s) Stakeholder(s) para o projeto
o(s) Stakeholder(s)
Facilitar a seleo do Time Scrum
Facilitar a criao do Plano de Colaborao e do Plano de Team Building
8.3 Formar o Time Scrum
Garantir a disponibilidade de backup de recursos para o bom
funcionamento do projeto
8.4 Desenvolver o(s) pico(s) Facilitar a criao de pico(s) e de Personas
8.5 Criar o Backlog Priorizado do Ajudar o Dono do Produto na criao do Backlog Priorizado do Produto e
Produto na definio dos Critrios de Pronto
8.6 Conduzir o Planejamento da Coordenar a criao do Cronograma de Planejamento da Release
Release Determinar a Durao do Sprint
Auxiliar o Time Scrum na criao das Estrias de Usurio e em seus
9.1 Criar as Estrias de Usurio
Critrios de Aceitao
9.2 Aprovar, Estimar e
Facilitar as reunies do Time Scrum para estimar e Criar as Estrias de
Compromoter as Estrias de
Usurio
Usurio
Facilitar ao Time Scrum a criao da Lista de Tarefas para o prximo
9.3 Criar as Tarefas
Sprint
Auxiliar o Time Scrum em estimar os esforos necessrios para
9.4 Estimar as Tarefas
completar as tarefas de acordo para o Sprint
Auxiliar o Time Scrum no desenvolvimento do Backlog do Sprint e do
9.5 Criar o Backlog do Sprint
Grfico Burndown do Sprint
Suportar o Time Scrum na criao das entregas acordadas para o Sprint
10.1 Criar os Entregveis
Ajudar a atualizar o Scrumboard e o Registro de Impedimentos
Garantir que o Scrumboard o Registro de Impedimentos continuem
10.2 Conduzir a Reunio Diria
sendo atualizados
10.3 Refinamento do Backlog
Facilitar as Reunies de Reviso do Backlog Priorizado do Produto
Priorizado do Produto
Garantir que os problemas que afetam o Time Scrum sejam discutidos e
11.1 Convocar o Scrum de Scrums
resolvidos
Facilitar a apresentao de entregas concludas pelo Time Scrum, para a
11.2 Demonstrar e Validar o Sprint
aprovao do Dono do Produto
Garantir a existncia de um ambiente ideal para o projeto, para o Time
11.3 Retrospectiva do Sprint
Scrum durante os Sprints seguintes
Representar o Time Central do Scrum, fornecendo lies do projeto
12.2 Retrospectiva do Projeto
atual, se necessrio

Tabela 3-2: Responsabilidades do Scrum Master em Processos Scrum

46 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.5.1 Scrum Master Chefe

Os grandes projetos requerem que mltiplos Times Scrum trabalhaem em paralelo. As informaes coletadas
por um time podem ter que ser devidamente comunicadas aos outros times. O Scrum Master Chefe
responsvel por esta atividade.

A Coordenao entre os vrios Times Scrum que trabalham em um projeto, geralmente feita atravs da
Reunio do Scrum de Scrums (SOS) (ver seo 3.7.2.1). Sendo similar Reunio Diria e facilitada pelo
Scrum Master Chefe. O Scrum Master Chefe tipicamente o indivduo responsvel por abordar os 3
impedimentos que impactam mais de um time Scrum.

A figura 3-2 fornece as perguntas que so feitas durante uma Reunio do Scrum de Scrums (SOS).

3. Quais so os seus
2. O que o seu time
impedimentos, e, os
ir concluir at a
outros times podem
prxima reunio
te ajudar?

4. Quais so as
1. No que o seu time
decises tomadas
tem trabalhado
pelo seu time que
desde a ltima
podem impactar
reunio? Scrum de outros times?
Scrums

Figura 3-2: As Perguntas feitas durante uma Reunio do Scrum de Scrums

Normalmente, todas as questes inter-times so abordadas pelas partes interessadas, em uma sesso que
ocorre imediatamente aps a Reunio do Scrum de Scrums. O Scrum Master Chefe facilita esta sesso.

3.6 Time Scrum


O Time Scrum muitas vezes referido como Time de Desenvolvimento, uma vez que so responsveis pelo
desenvolvimento do produto, servio ou de outro resultado. Trata-se de um grupo de indivduos que
trabalham nas Estrias de Usurio do Backlog do Sprint para criar as entregas para o projeto.

A tabela 3-3 resume as responsabilidades do Time Scrum nos vrios processos Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 47


3 ORGANIZAO

Processos Responsabilidades do Time Scrum


Fornecer inputs para a criao do Plano de Colaborao e Plano de Team
8.3 Formar o Time Scrum
Building
8.4 Desenvolver os pico(s) Garantir uma compreenso clara sobre os pico(s) e Personas
8.5 Backlog Priorizado do Produto Compreender as Estrias de Usurio no Backlog Priorizado do Produto
Concordar com outros membros do Time Cental do Scrum sobre a Durao do
8.6 Conduzir o Planejamento da Sprint
Release Buscar esclarecer novos produtos, ou mudanas nos produtos j existentes, se
houver, no Backlog Priorizado do Produto refinado
9.1 Criar as Estrias de Usurio Fornecer inputs para o Dono do Produto na criao das Estrias de Usurio
9.2 Aprovar, Estimar e
Estimar as Estrias de Usurio aprovadas pelo Dono do Produto
Compromoter as Estrias de
Comprometer as Estrias de Usurio a serem concludas no Sprint
Usurio
Desenvolver a Lista de Tarefas com base em Estrias de Usurio e dependncias
9.3 Criar as Tarefas
acordadas
Estimar os esforos para as tarefas identificadas e, se necessrio, atualizar a Lista
9.4 Estimar as Tarefas
de Tarefas
9.5 Criar o Backlog do Sprint Desenvolver o Backlog do Sprint e o Grfico Burndown do Sprint
Criar os Entregveis
10.1 Criar os Entregveis Identificar riscos e e implementar aes de mitigao de risco, se houver
Atualizar o Registro de Impedimento e dependncias
Atualizar o Grfico Burndown, Scrumboard, e Registro de Impedimentos
Discutir problemas enfrentados por membros individuais, e buscar solues para
10.2 Conduzir a Reunio Diria motivar o time
Identificar riscos, se houver
Submeter Solicitaes de Mudana, se necessrio
10.3 Refinamento do Backlog
Participar em Reunies de Reviso do Backlog Priorizado do Produto
Priorizado do Produto
11.1 Convocar o Scrum de
Fornecer inputs ao Scrum Master para Reunies do Scrum de Scrums (SoS)
Scrums
11.2 Demonstrar e Validar o
Demonstrar ao Dono do Produto as entregas concludas, que requerem aprovao
Sprint
Identificar oportunidades de melhorias, se houver, no Sprint atual e concordar
11.3 Retrospectiva do Sprint
com todas as melhorias viveis para o prximo Sprint
12.2 Retrospectiva do Projeto Participar da Reunio de Retrospectiva do Projeto

Tabela 3-3: Responsabilidades do Time Scrum em Processos do Scrum

48 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.6.1 Seleo de Pessoal

A figura 3-3 lista as caractersticas desejveis para os papis centrais do Scrum.

Expert em Scrum Expert em Scrum Conhecimento em Scrum 3


Domnio de Lder Servidor Colaborativo
conhecimento do negcio Moderador Auto-organizado
Habilidade de Resolve problemas Altamente Motivado
comunicao excelente Acessvel Proactivo
Dono do Produto

Conhecimento dos Motivador Especialistas Tcnicos


processos do Scrum Perceptivo Perspectiva
Habilidade para lidar com
Scrum Master
Mentor multifuncional
incertezas Trabalha em Times
Habilidades de

Time Scrum
Habilidades de Coordenao Independente
Negociao
Introspectivo Responsvel
Acessvel
Intuitivo
Proativo
Foco nos objetivos
Decisivo
Introspectivo
Pragmtico
Foco nos objetivos

Figura 3-3: Caractersticas Desejveis para os Papis Centrais do Scrum

3.6.2 Tamanho do Time Scrum

importante que o Time Scrum possua todas as habilidades essenciais necessrias para realizar o trabalho
do projeto. Tambm necessrio que haja um alto nvel de colaborao para maximizar a produtividade, de
modo que mnima coordenao seja necessria.

O tamanho ideal de um Time Scrum de seis a dez membros, grande o suficiente para garantir que sejam
adquiridos os conjuntos de habilidades adequadas, mas pequeno o suficiente para facilitar a colaborao.
Entre os principais benefcios de se formar um time de seis a dez membros, esto a comunicao e o
gerenciamento, que ocorrem normalmente de forma simples e requerem esforos mnimos. No entanto, s
vezes podem ser inconvenientes, um grande problema est no fato de times menores serem
significativamente mais afetados pela perda de um membro, mesmo que por um curto perodo de tempo, o
que pode no afetar da mesma forma times maiores. Para resolver este problema, possvel que os
membros do time tenham habilidades e conhecimentos especializados fora do seu prprio papel especfico.
No entanto, isso pode ser difcil e depende do tipo de projeto, indstria e tamanho da organizao.
Recomenda-se ter pessoas que atuem como backup caso seja necessrio substituir qualquer membro do
Time Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 49


3 ORGANIZAO

3.7 Scrum em Projetos, Programas e Portflios


3.7.1 Definio de Projeto, Programa e Portflio

ProjetoUm projeto um empreendimento colaborativo com o objetivo de criar novos produtos ou


servios, ou para entregar resultados conforme definido na Declarao da Viso do Projeto. Os projetos
so geralmente afetados por restries de tempo, custo, escopo, qualidade, pessoas e capacidades
organizacionais. O objetivo do time do projeto o de criar entregas conforme definido no Backlog
Priorizado do Produto.

ProgramaUm programa um grupo de projetos relacionados, com o objetivo de entregar resultados


de negcio, conforme definido na Declarao da Viso do Programa. O Backlog Priorizado do Programa
incorpora os Backlogs Priorizados dos Produtos para todos os projetos do programa.

PortflioO portflio um grupo de programas relacionados, com o objetivo de entregar resultados de


negcio, conforme definido na Declarao da Viso do Portflio. O Backlog Priorizado do Portflio
integra os Backlogs Priorizados dos Programas para todos os programas do portflio.

A seguir, exemplos de projetos, programas e portflios de diferentes indstrias e setores:

Exemplo 1: Construtora

ProjetoA construo de uma casa


ProgramaConstruo de um complexo habitacional
PortflioTodos os projetos de construes habitacionais da empresa

Exemplo 2: Organizao Aeroespacial

Projeto Construo do veculo de lanamento


ProgramaLanamento bem sucedido de um satlite
PortflioTodos os programas de satlites ativos

Exemplo 3: Empresa deTecnologia da Informao (TI)

ProjetoMdulo de desenvolvimento do carrinho de compras


ProgramaDesenvolvimento totalmente functional de um website e-commerce
PortflioTodos os websites desenvolvidos pela empresa at agora

50 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.7.2 Scrum em Projetos

J que o Scrum favorece pequenos grupos, pode-se pensar que este mtodo s pode ser utilizado em
pequenos projetos, mas este no o caso. O Scrum tambm pode ser utilizado de forma eficaz em projetos
de grande escala. Quando mais de dez pessoas so necessrias para realizar o trabalho, vrios Times
Scrum podem ser formados. O time do projeto composto por vrios Times Scrum trabalhando em conjunto
para criar os Entregveis e as Releases dos Produtos, de modo a alcanar os resultados gerais desejados
pelo projeto. 3
Uma vez que um projeto pode ter vrios Times Scrum trabalhando em paralelo, a coordenao entre
diferentes times se torna importante. A coordenao e comunicao entre os Times Scrum geralmente ocorre
de vrias maneiras, no entanto, a abordagem mais comum conhecida como Reunio do Scrum de Scrums
(SOS). Os membros que representam cada Time Scrum se renem para discutir progressos, problemas e
para coordenar as atividades entre os times. Estas reunies so semelhantes em formato, as Reunies
Dirias. Porm, a frequncia com que as reunies do Scrum de Scrums ocorrem pode variar entre intervalos
pr-determinados, ou serem coordenadas conforme exigido pelos diferentes Times Scrum.

3.7.2.1 Reunio do Scrum de Scrums (SoS)

A Reunio do Scrum de Scrums (SoS) um elemento importante quando se usa o Scrum para grandes
projetos. Normalmente, um representante de cada Time Scrum est presente durante esta reunio,
geralmente o Scrum Master, mas tambm se for necessrio, comum que qualquer outro membro do Time
Scrum participe da reunio. Geralmente facilitada pelo Scrum Master Chefe e seu foco destinado em
reas de coordenao e integrao entre os diferentes Times Scrum. Esta reunio realizada em intervalos
pr-determinados ou quando exigido pelos Times Scrum.

Em organizaes que possuem vrios Times Scrum trabalhando ao mesmo tempo em partes de um projeto,
a Reunio do SoS pode ser escalada para outro nvel, referido como Reunio do Scrum de Scrum de
Scrums. Nesta situao, uma Reunio do SoS realizada para coordenar cada grupo dos Times Scrum que
estejam trabalhando em partes de um projeto relacionado e, em seguida, uma Reunio do Scrum de Scrum
de Scrums poder ser realizada para coordenar e integrar os projetos a um nvel superior. Os times tm que
avaliar cuidadosamente os benefcios da da realizao das Reunies do Scrum de Scrum de Scrums, j que
a terceira camada acrescenta uma quantidade significativa de complexidade logstica.

A figura 3-4 ilustra o conceito das Reunies do Scrum de Scrums (SOS) e do Scrum de Scrum de Scrums.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 51


3 ORGANIZAO

Figura 3-4: Reunies do Scrum de Scrums (SOS)

Neste exemplo, existem seis Times Scrum trabalhando simultaneamente. Os Times Scrum A, B, e C esto
trabalhando em partes de um projeto relacionado, enquanto os Times Scrum D, E, e F esto trabalhando em
partes de outro projeto relacionado. A Reunio do Scrum de Scrums realizada para coordenar as
interdependncias entre os projetos relacionados, enquanto que a Reunio do Scrum de Scrums de Scrums
pode ento ser conduzida para coordenar e gerenciar as dependncias entre todos os projetos.

52 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.7.3 Scrum em Portflios e Programas


3.7.3.1 Portflios

Em portflios, os papis importantes para gerir os portflio do Scrum so:

1. Dono do Produto do PortflioDefine os objetivos estratgicos e as prioridades para o portflio.

2. Scrum Master PortflioResolve problemas, remove impedimentos, facilita, e realiza as reunies 3


para o portflio.

Essas funes so semelhantes s do Dono do Produto e do Scrum Master, exceto que, atendem s
necessidades do portflio ou empresa, ao invs das necessidades de um nico Time Scrum.

3.7.3.2 Programas

Em programas, os papis importantes para gerir os programas do Scrum so:

1. Dono do Produto do ProgramaDefine os objetivos estratgicos e as prioridades para o


programa.

2. Scrum Master do Programa Resolve problemas, remove impedimentos, facilita, e realiza as


reunies para o programa.

Essas funes so semelhantes s do Dono do Produto e do Scrum Master, exceto que, atendem s
necessidades do programa ou empresa, ao invs das necessidades de um nico Time Scrum.

A figura 3-5 ilustra como o Scrum pode ser utilizado em toda a organizao para portflios, programas ou
projetos.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 53


3 ORGANIZAO

Figura 3-5: Scrum em Toda a Organizao para Projetos, Programas e Portflios

3.7.3.3 Trabalhando com Times de Portflios e Programa

Ao aplicar o Scrum no gerenciamento de projetos dentro do contexto de programa ou portflio, altamente


recomendvel que os princpios gerais do Scrum apresentados nesta publicao sejam respeitados. Entende-
se, porm, que, a fim de acomodar as interdependncias e atividades gerais do programa ou portflio,
pequenos ajustes podem ser necessrios, para o conjunto de ferramentas, bem como, para a estrutura
organizacional. Se o Scrum Guidance Body existir, este pode ser responsvel por fiscalizar a organizao em
diferentes nveis, por entender e definir a aplicao adequada do Scrum, e para atuar como um rgo de
consulta para todos os membros que trabalham em um projeto, programa ou portflio.

Os Portflios e programas tm times separados, com diferentes conjuntos de objetivos. Times de


gerenciamento do programa visam oferecer recursos e realizar certos objetivos que contribuem para a
realizao dos objetivos especficos do programa. Enquanto que, o time de portflio tenta equilibrar os
objetivos de vrios programas para atingir os objetivos estratgicos da organizao como um todo.

54 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.7.3.4 Gerenciando a Comunicao entre os Times de Portflios e Programa

Os problemas e questes enfrentados quando se utiliza o Scrum dentro do programa ou portflio, envolvem
principalmente a coordenao entre vrios times. Podendo levar ao fracasso se no for cuidadosamente
gerenciada. As Ferramentas utilizadas para a comunicao precisam ser dimensionadas para
corresponderem s exigncias dos times envolvidos no programa ou portflio. Cada Time Scrum deve
abordar no apenas as comunicaes internas, mas tambm as comunicaes externas, com outros times e
com os stakeholders do programa ou portflio.
3

3.7.4 Mantendo o envolvimento do Stakeholder

O Scrum requer apoio completo dos stakeholders do projeto. O Dono do Produto o responsvel por manter
os stakeholders envolvidos no projeto.

Aes recomendadas para a manuteno do engajamento dos stakeholders e apoio:

Certifique-se de que o stakeholder esteja envolvido e que colabore efetivamente no projeto


Avalie continuamente o impacto nos negcios
Mantenha uma comunicao regular com os stakeholders
Gerencie as expectativas dos stakeholders

O patrocinador um dos principais stakeholders, o indivduo que fornece o financiamento e outros recursos
para um projeto. Os Patrocinadores querem entender a linha de fundos financeiros relacionadas a um
produto ou servio, e tipicamente esto mais preocupados com os resultados finais do que com as tarefas
individuais.

importante que os patrocinadores que financiam o projeto entendam as seguintes questes:

Benefcios da implementao do Scrum


Prazos esperados e custos estimados dos projetos Scrum
Riscos gerais envolvidos em projetos Scrum e as medidas para mitig-los
Datas de lanamento esperadas e resultados finais

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 55


3 ORGANIZAO

3.8 Resumo das Responsabilidades

Papis Responsabilidades
Estabelecer as diretrizes e as medidas gerais para o desenvolvimento da descries dos
papis para os membros do Time Scrum
Scrum Guidance Body Atuar como consultor de projetos em diferentes nveis para toda a organizao
Entender e definir os nveis adequados de agrupamento, de papis e de reunies para os
projetos Scrum
Dono do Produto do
Definir os objetivos estratgicos e as prioridades para os portflios
Portflio
Scrum Master do Portflio Resolver os problemas e coordenar as reunies para os portflios
Dono do Produto do
Definir os objetivos estratgicos e as prioridades para os programas
Programa
Scrum Master do
Resolver os problemas e coordenar as reunies para os programas
Programa
um termo coletivo que inclui clientes, usurios e patrocinadores
Stakeholder(s) Interagir frequentemente com o Dono do Produto, Scrum Master e com o Time Scrum,
para fornecer inputs e facilitar a criao das entregas do projeto.
Criar os requisitos iniciais gerais do projeto e manter o projeto em andamento
Nomeiar as pessoas adequadas para os papis de Scrum Master e Time Scrum
Fornecer os recursos financeiros para o incio do projeto e durante o seu andamento
Determinar a Viso do Projeto
Avaliar a viabilidade e garantir a entrega do produto ou servio
Dono do Produto Garantir a transparncia e e clareza dos itens do Backlog Priorizado do Produto
Decidir o contedo mnimo para release comercial
Fornecer os Critrios de Aceitao para as Estrias de Usurio a serem desenvolvidas em
um Sprint
Inspecionar as entregas
Decidir a durao do Sprint
Garantir que os processos do Scrum sejam corretamente seguidos por todos os membros
do time, incluindo o Dono do Produto
Assegurar que o desenvolvimento do produto ou servio est ocorrendo sem problemas e
Scrum Master
que os membros do Time Scrum tem todas as ferramentas necessrias para a realizao
do trabalho
Supervisionar a Reunio de Planejamento da Release e agendar as outras reunies
Assumir a responsabilidade coletiva e garantir que as entregas do projeto sejam criadas de
acordo com os requisitos
Time Scrum
Garantir ao Dono do Produto e ao Scrum Master que o trabalho alocado est sendo
realizado de acordo com o plano

Tabela 3-4: Resumo das Responsabilidades Relevantes Organizao

56 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.9 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


Uma estrutura organizacional, e a definio de papis e responsabilidades associadas, so algumas das
reas onde o Scrum se difere de forma significativa dos mtodos tradicionais de gerenciamento de projetos.

Nos mtodos tradicionais de gerenciamento de projetos, a estrutura da organizao hierrquica e a


autoridade para todos os aspectos do projeto, delegada do nvel superior ao inferior, por exemplo, o
patrocinador do projeto delega autoridade para o gerente do projeto, que por sua vez delega autoridade aos
3
membros do time. Os mtodos tradicionais de gerenciamento de projetos enfatizam o indivduo, sendo
responsvel pela prestao de contas do projeto, ao invs do grupo. Qualquer desvio de autoridade delegada
encarado como um sinal de problema, e pode ser escalado para o nvel mais alto da hierarquia da
organizao. Geralmente o gerente do projeto responsvel pela concluso bem sucedida do projeto, e ele
ou ela toma as decises sobre vrios aspectos do projeto, incluindo: incio, planejamento, estimativas,
execuo, monitoramento e controle, e encerramento.

A nfase do Scrum est na auto-organizao e auto-motivao, onde o time assume uma responsabilidade
maior pelo projeto, comprometendo-se com o seu sucesso. Isso tambm garante que o time buy-in e
compartilhe responsabilidades. O que por sua vez, resulta em motivao conduzindo a otimizao da
eficincia do time. O Dono do Produto, o Scrum Master, e o Time Scrum trabalham em conjunto com o(s)
Stakeholder(s) relevantes, para refinar os requisitos enquanto passam pelo processos de Desenvolver o(s)
pico(s), Criar o Backlog Priorizado do Produto, e Criar as Estrias de Usurio. Isso garante que no haja
espao para o planejamento isolado em Scrum. A experincia do time e sua expertise no desenvolvimento de
produtos, so utilizadas para avaliar as entradas necessrias para planejar, avaliar e executar os trabalhos do
projeto. A colaborao entre os membros do Time Central do Scrum, garante que o projeto seja realizado em
um ambiente inovador e criativo, favorvel harmonia e ao crescimento do time.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 57


3 ORGANIZAO

3.10 Teorias Populares de RH e suas Relevncias para o Scrum


3.10.1 O Modelo de Tuckman de Dinmica de Grupo

Para um Time Scrum novo, a abordagem e o mtodo do Scrum, podem parecer inicialmente um pouco difcil e
diferente. Como em qualquer outro time novo, sua evoluo acontece geralmente atravs de um processo de
quatro etapas, durante o seu primeiro projeto Scrum. Este processo conhecido como modelo de Tuckman de
dinmicas de grupo (Tuckman, 1965). A ideia principal que as quatro etapas (Formao, Tempestade,
Normatizao e Realizao) so fundamentais no desenvolvimento de um time, atravs da mitigao dos
problemas e desafios, encontrando solues no planejamento do trabalho, e na obteno de resultados.

As quatro etapas do modelo so as seguintes:

1. FormaoMuitas vezes considerada como uma fase divertida, porque tudo novo e o time ainda
no encontrou dificuldades com o projeto.
2. TempestadeDurante esta fase, o time tenta realizar o trabalho; no entanto, podem ocorrer
tentativas de liderana o que gera muitas vezes, caos ou confuso entre os membros do time.
3. Normatizao Quando o time comea a amadurecer, a resolver as suas diferenas internas, e a
encontrar solues para trabalhar em conjunto. considerado um perodo de adaptao.
4. Realizao Durante esta fase, o time se torna mais coeso e atua em seu nvel mais alto, em
termos de desempenho. Os membros evoluem em um time de profissionais eficientes que so
consistentemente produtivos.

Figura 3-6: Etapa Tuckman de Desenvolvimento de Grupo

58 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.10.2 Gerenciamento de Conflitos

As organizaes que aplicam o framework Scrum incentivam um ambiente aberto e de dilogo entre os seus
colaboradores. Os conflitos entre os membros do Time Scrum so geralmente resolvidos de forma
independente, com pouco ou nenhum envolvimento dos gerentes, ou outros fora do Time Scrum.

O conflito pode ser saudvel quando promove discusses em time e estimula debates, o que geralmente
resulta em benefcios para o projeto e para os respectivos membros do time. Por isso, importante que a
resoluo de conflitos seja encorajada, promovendo um ambiente aberto, onde os membros do time se 3
sentem vontade para expressar suas opinies e preocupaes com o outro, e com o projeto, e finalmente,
chegar a um acordo sobre o que deve ser entregue, e de como ser realizado o trabalho em cada Sprint.

As tcnicas de gerenciamento de conflitos so utilizadas pelos membros do time, para gerenciar os conflitos
que possam surgir durante um projeto Scrum. As fontes de conflitos evoluem principalmente devido a:
cronogramas, prioridades, recursos, hierarquia de informao, problemas tcnicos, procedimentos,
personalidade e custos.

3.10.3 Tcnicas de Gerenciamento de Conflitos

Normalmente existem quatro abordagens para o gerenciamento de conflitos em uma organizao que aplica
os processos Scrum:

1. Ganho-Ganho
2. Perda-Ganho
3. Perda-Perda
4. Ganho-Perda

3.10.3.1 Ganho-Ganho

Geralmente melhor que os membros time enfrentem os problemas diretamente com uma atitude de
cooperao e com dilogo aberto, para esclarecer todos os desentendimentos e chegar a um consenso. Esta
abordagem chamada de Ganho-Ganho. As organizaes que implementam o Scrum devem promover um
ambiente em que os seus colaboradores se sintam confortveis para discutirem abertamente e confrontarem
problemas, buscando solucion-los de forma que os resultados sejam de Ganho-Ganho.

3.10.3.2 Perda-Ganho

Alguns membros do time podem por vezes, sentirem que suas contribuies no esto sendo reconhecidas
ou valorizadas pelos outros, ou que no esto sendo tratados igualmente. Isso pode lev-los a deixarem de
contribuir de forma eficaz para o projeto, concordando e atuando de acordo com o que for requisitado,

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 59


3 ORGANIZAO

mesmo que discordem. Esta abordagem chamada de Perda-Ganho. Esta situao pode acontecer se
houverem membros no time (incluindo gerentes) que usam um estilo autoritrio ou diretivo, de emisso de
ordens e/ou no tratam todos os membros do time da mesma forma. Esta abordagem no uma tcnica de
gerenciamento de conflitos desejada para projetos Scrum, uma vez que a contribuio ativa de cada membro
do time obrigatria para a concluso bem sucedida de cada Sprint. O Scrum Master deve incentivar o
envolvimento de todos os membros do time que aparentemente evitem situaes de conflito. Por exemplo,
importante para todos os membros do time falarem e contribuirem em cada Reunio Diria, para que
quaisquer problemas ou impedimentos se tornem de conhecimento geral, para serem gerenciados de forma
eficaz.

3.10.3.3 Perda-Perda

Em situaes de conflito, os membros do time podem tentar negociar ou procurar solues que tragam
apenas um grau parcial ou uma medida provisria de satisfao para as partes em conflito. Esta situao
pode acontecer em Times Scrum onde os membros do time tentam resolver os problemas com solues de
qualidade de baixo nvel. Esta abordagem geralmente envolve o termo "dar e receber" onde procura-se
satisfazer cada membro do time, ao invs de tentar resolver o problema real. Isso geralmente resulta em
Perda-Perda, para as pessoas envolvidas e, consequentemente, para o projeto. O Time Scrum deve ter
cuidado para garantir que os membros do time no entrem em uma mentalidade de Perda-Perda. A Reunio
Diria e as outras reunies do Scrum so realizadas para garantir que os problemas atuais sejam resolvidos
atravs de discusses mtuas.

3.10.3.4 Ganho-Perda

s vezes, um Scrum Master, ou um membro influente do time, pode acreditar que ele ou ela o lder de fato,
ou o gerente, e tentar exercer seu ponto de vista em detrimento do ponto de vista dos outros. Esta tcnica de
gerenciamento de conflitos muitas vezes caracterizada pela competitividade e, normalmente, resulta em
Ganho-Perda. Esta abordagem no recomendada quando se trabalha de projetos Scrum, porque os Times
Scrum so por natureza, auto-organizados e capacitados, sem que exista a necessidade de se exercer
autoridade sobre os demais membros do time. Embora o Time Scrum possa incluir pessoas com diferentes
nveis de experincia e expertise, todos os membros devem ser tratados igualmente, e nenhum membro deve
ter autonomia na tomada de decises.

60 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

3.10.4 Estilos de Liderana

Os estilos de liderana variam de acordo com: a organizao, a situao, e at mesmo com os indivduos e
com os objetivos especficos do projeto Scrum. Alguns estilos de liderana comuns so:

Liderana ServidoraLderes Servidores empregam a escuta, a empatia, o comprometimento e a


introspeco, ao compartilhar poder e autoridade com os membros do time. Os lderes servidores
alcanam resultados, focando as necessidades do time. Este estilo a personificao do papel do Scrum 3
Master.
DelegaoOs Lderes de Delegao esto envolvidos na maioria das tomadas de decises; no
entanto, eles delegam algumas responsabilidades de planejamento e de tomada de decises aos
membros do time, especialmente se estes membros so capazes de lidar com as tarefas. Este estilo de
liderana apropriado em situaes em que o lder est focado em detalhes especficos do projeto, e
quando o seu tempo limitado.
AutocrticoOs Lderes autocrticos tomam decises por conta prpria, permitindo aos membros do
time pouco, ou nenhum envolvimento na tomada de decises. Este estilo de liderana deve ser usado
somente em raras ocasies.
DireoO Lder de Direo instrui os membros do time sobre as tarefas que so necessrias, quando
e como elas devem ser realizadas.
Laissez FaireCom este estilo de liderana, o time deixado sem superviso, e o lder no interfere
nas atividades dirias de trabalho. Isso muitas vezes leva a um estado de anarquia.
Apoio/ TreinamentoOs Lderes de apoio e treinamento emitem instrues e, em seguida, apoiam e
monitoram os membros do time atravs da escuta, ajudando, incentivando, e apresentando uma
perspectiva positiva em momentos de incerteza.
Orientador de TarefaOs Lderes Orientadores de Tarefas impem a concluso de tarefas e o
cumprimento de prazos.
AssertivoOs Lderes assertivos enfrentam problemas e demonstram confiana para estabelecerem
autoridade com respeito.

3.10.4.1 Liderana Servidora

Liderana Servidora o estilo de liderana preferido para projetos Scrum. Este termo foi primeiramente
descrito por Robert K. Greenleaf em um ensaio intitulado The Servant as Leader (O Servidor como Lder).
Abaixo est um trecho onde ele explica o conceito:

O lder-servidor, servidor em primeiro lugar... Comea com o sentimento natural de que se deve
servir, para ser servido. Ento a escolha consciente leva a pessoa a aspirar a liderana. Essa
pessoa drasticamente diferente de quem lder em primeiro lugar, talvez por causa da
necessidade de satisfazer uma unidade de energia incomum ou para adquirir bens materiais ... O

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 61


3 ORGANIZAO

lder em primeiro lugar, e o servidor em primeiro lugar, so dois tipos extremos. Entre eles, h
nuances e misturas que fazem parte da variedade infinita da natureza humana.

A diferena se manifesta no cuidado com que o servidor em primeiro lugar, tem em se certificar de
que as necessedades de alta prioridade de outras pessoas esto sendo atendidas. O melhor teste, e
difcil de administrar, : Ser que aqueles que foram servidos crescem como pessoa? Ser que eles,
ao serem servidos, se tornam mais saudveis, sbios, livres, autnomos, mais propcios a se
tornarem servidores? E, qual o efeito da sociedade sobre os menos privilegiados? Ser que eles
sero beneficiados, ou pelo menos passaram a no serem privados? (Greenleaf 1970, 6)

Baseando-se nos escritos de Greenleaf, Larry Spears identifica dez traos que todo lder-servidor eficaz deve
possuir:

1. OuvirEspera-se que os lderes servidores ouam atenta e receptivamente ao que est sendo dito,
ou no dito. Eles so capazes de entrar em contato com a sua voz interior para compreender e
refletir sobre seus prprios sentimentos.

2. EmpatiaBons lderes servidores aceitam e reconhecem indivduos por suas competncias e


habilidades, especiais e nicas. Eles assumem que os colaboradores tm boas intenes e os
aceitam como indivduos, mesmo quando existem problemas de comportamento ou desempenho.

3. CuraA motivao e potencial para curar a si mesmo e a outros, um trao forte em lderes
servidores. Os lderes servidores reconhecem e aproveitam oportunidades de ajudar os seus
colegas, que esto passando por fases emocionais.

4. ConscinciaA Conscientizao e particularmente, a auto-conscincia, um trao em lderes


servidores. Isto lhes permite compreender melhor e integrar os problemas relacionados a, tica,
poder e valores.

5. PersuasoOs lderes servidores usam a persuaso, ao invs de sua autoridade posicional, para
chegar a um consenso em grupo e tomar decises. Ao invs de forar o cumprimento, e coero,
como tpico em alguns estilos de gerenciamento autoritrios, os lderes servidores praticam a
persuaso.

6. ConceituaoA capacidade de visualizar e analisar os problemas (em uma organizao), a partir


de uma perspectiva conceitual e visionria mais ampla, ao invs de focar apenas nos objetivos
imediatos de curto prazo, uma habilidade nica de bons lderes servidores.

7. PrevisoSuas mentes intuitivas permitem que os lderes servidores usem e apliquem lies
passadas e realidades presente para prever o resultado de situaes, e decises atuais.

62 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


3 ORGANIZAO

8. StewardshipO Stewardship exige um compromisso de servir aos outros. Os lderes servidores


preferem persuaso, ao invs de controle, para garantir que ganharo a confiana de outras pessoas
na organizao.

9. Compromisso com o crescimento de outrosOs lderes servidores tm um profundo


compromisso com o crescimento das pessoas que trabalham dentro de sua organizao. Eles
assumem a responsabilidade de nutrir o crescimento pessoal, profissional e espiritual dos outros, por
exemplo; o fornecimento de acesso a recursos para o desenvolvimento pessoal e profissional, 3
incentivando a participao dos colaboradores na tomada de decises.

10. Construindo a comunidadeOs lderes servidores esto interessados na construo de


comunidades dentro de um ambiente de trabalho, levando em considerao as mudanas nas
sociedades, longe de comunidades menores, para grandes instituies que moldam e controlam
vidas humanas.

O Scrum acredita que todos os lderes de projetos Scrum (incluindo o Scrum Master e o Dono do Produto)
devem ser lderes servidores, possuindo as caractersticas acima.

3.10.5 Teoria de Maslow sobre a Hierarquia de Necessidades

Maslow (1943) apresentou uma hierarquia de necessidades que reconhece que pessoas diferentes esto em
nveis diferentes em suas necessidades. Normalmente as pessoas comeam a olhar para as necessidades
fisiolgicas e, depois, progressivamente vo subindo na hierarquia de necessidades.

Figura 3-7: Teoria de Maslow sobre Hierarquia das Necessidades

Para ser bem sucedido, um Time Scrum precisa tanto de membros dos times centrais, como no-essenciais,
que tenham atingido os nveis de estima ou auto-realizao. O conceito de times auto-organizados, um
princpio fundamental em Scrum, exigindo que os membros do time sejam auto-motivados, que participem e
contribuam plenamente para o cumprimento dos objetivos do projeto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 63


3 ORGANIZAO

Como lder, o Scrum Master precisa entender em que nvel cada pessoa do time se encontra, na pirmide de
hierarquia de necessidades. Este entendimento ajuda a determinar a melhor abordagem para motivar cada
indivduo.

Alm disso, os nveis de todo mundo oscila para cima e para baixo, ao longo de suas vidas, devido
motivao prpria e esforos para subir na hierarquia ou, por vezes, devido a fatores fora de seu controle,
que podem empurr-los para baixo. O objetivo do Scrum Master trabalhar com os membros do time, para
construir habilidades e conhecimentos e ajud-los a subir na hierarquia de necessidades. Este suporte resulta
em um time que composto por indivduos que so motivados, e fortes colaboradores para o projeto e para a
organizao como um todo.

3.10.6 Teoria X e Teoria Y

Douglas McGregor (1960) props duas teorias de gerenciamento:

Teoria XOs Lderes da Teoria X assumem que os colaboradores so inerentemente desmotivados


e que se possvel, evitaro o trabalho, garantindo um estilo de gerenciamento autoritrio.

Teoria YOs Lderes da Teoria Y, por outro lado, assumem que os colaboradores so auto-
motivados e buscam aceitar maiores responsabilidades. A Teoria Y envolve um estilo de
gerenciamento mais participativo.

Os Projetos Scrum provavelmente no sero bem sucedidos, quando as organizaes tiverem lderes que
atuem de acordo com a Teoria X, nos papis de Scrum Master ou Dono do Protudo. Todos os lderes em
projetos Scrum devem basear-se na Teoria Y, vendo os indivduos como ativos importantes, buscando
desenvolver as habilidades e capacidade de empoderamento dos membros do time, e devendo ao mesmo
tempo expressar apreciao pelo trabalho que est sendo realizado para alcanar os objetivos do projeto.

64 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

4. JUSTIFICATIVA DE NEGCIO

4.1 Introduo
O objetivo deste captulo entender o conceito e a finalidade da Justificativa de Negcio no que se refere
aos projetos Scrum. Antes de se iniciar qualquer projeto, importante para uma organizao a realizao
de uma Justificativa de Negcio adequada, e a criao de uma Declarao da Viso do Projeto vivel.
Tambm ajuda o Dono do Produto a criar um Backlog Priorizado do Produto, com as expectativas de 4
negcios da Alta Administrao e do(s) Stakeholder(s).

A Justificativa de Negcio, tal como definida no Guia para o Conhecimento em Scrum (Guia SBOK),
aplicvel ao:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Este captulo est dividido nas seguintes sees:

4.2 Guia de Papis Esta seo fornece orientao sobre quais sees so relevantes para cada um dos
papis centrais do Scrum: Dono do Produto, Scrum Master, e Time Scrum.

4.3 Entrega orientada a ValorEsta seo descreve o conceito de valor do negcio e a sua importncia
em qualquer projeto. Tambm fornece informaes sobre as responsabilidades dos vrios indivduos
envolvidos em alcanar o valor do negcio, incluindo o Dono do Produto.

4.4 A Importncia da Justificativa de NegcioEsta seo detalha a importncia da justificativa de


negcio, os fatores que a determinam, e como ela mantida e verificada ao longo do projeto.

4.5 As Tcnicas da Justificativa de NegcioEsta seo descreve em detalhes como a justificativa de


negcio avaliada e verificada, utilizando-se vrias ferramentas.

4.6 Justificativa de Valor ContnuoEsta seo detalha a importncia da justificativa de valor contnuo, e
como ele alcanado.

4.7 Confirmar a Realizao de BenefciosEsta seo descreve como os benefcios so realizados


durante todo o projeto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 65


4 JUSTIFICATIVA DE NEGCIO

4.8 Resumo das ResponsabilidadesEsta seo define as responsabilidades relevantes a justificativa de


negcio para os membros do time do projeto, com base em seus papis.

4.9 Scrum x O Modelo Tradicional de Gerenciamento de ProjetosEsta seo destaca os benefcios


do mtodo Scrum em relao aos modelos tradicionais de gerenciamento de projetos.

4.2 Guia de Papis


1. Dono do ProdutoA Justificativa de Negcio realizada principalmente pelo Dono do Produto;
portanto, a maior parte deste captulo aplicvel a este papel.

2. Scrum MasterO Scrum Master deve estar familiarizado com este captulo inteiro, com foco
principal nas sees 4.3, 4.4, 4.6, 4.7 e 4.8.

3. Time ScrumO Time Scrum deve se concentrar principalmente nas sees 4.3, 4.7 e 4.8.

4.3 Entrega Orientada a Valor


Um projeto um empreendimento colaborativo para criar novos produtos ou servios, ou para entregar
resultados, conforme definido na Declarao da Viso do Projeto. Os projetos so geralmente afetados por
restries de tempo, custo, escopo, qualidade, pessoas e capacidades organizacionais. Normalmente, os
resultados gerados pelos projetos devem criar algum tipo de valor de negcio ou servio.

Como o valor a razo principal para qualquer organizao prosseguir com um projeto, a entrega orientada
a valor deve ser o foco principal. A entrega de valor est entranhada no framework Scrum. O Scrum facilita
a entrega de valor muito cedo no projeto, e continuamente durante o seu ciclo de vida.

A incerteza dos resultados uma das caractersticas-chave de qualquer projeto. impossvel garantir o
sucesso do projeto em sua concluso, independentemente de seu tamanho ou complexidade.
Considerando-se essa incerteza de alcance de sucesso, importante comear a produzir resultados, o
mais cedo possvel. Esta entrega antecipada de resultados, e mutuamente de valor, oferece uma
oportunidade para reinvestimento e comprova para os stakeholders o valor do projeto.

Com a finalidade de proporcionar a entrega orientada a valor, importante:

1. Entender o que agrega valor aos clientes e usurios, e priorizar os requisitos de alto valor no topo
do Backlog Priorizado do Produto.

2. Diminuir a incerteza e constantemente direcionar os riscos, que potencialmente possam diminuir o


valor, caso ocorram. Tambm, trabalhar em colaborao com os stakeholders do projeto,
mostrando-lhes incrementos de produtos no final de cada Sprint, permitindo o gerenciamento
eficaz de mudanas.

66 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

3. Criar os Entregveis com base nas prioridades definidas pela produo de incrementos de
produtos potencialmente entregveis em cada Sprint, para que os clientes possam perceber o valor
j no incio do projeto.

O conceito de entrega orientada a valor em Scrum, faz com que o framework Scrum seja muito atraente
para os stakeholders e para a alta gerncia. Este conceito muito diferente quando comparado com os de
modelos tradicionais de gerenciamento de projetos, onde:

1. Os requisitos no so priorizados pelo valor de negcio.


2. A mudana de requisitos aps o incio do projeto difcil, e s pode ser feita atravs de um
processo demorado de gerenciamento de mudana. 4
3. O valor realizado apenas no final do projeto, quando o produto ou servio final entregue.

A figura 4-1 contrasta a Entrega Orientada a Valor em Scrum versus Projetos tradicionais.

Figura 4-1: Entregando Valor em Scrum x Projetos Tradicionais

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 67


4 JUSTIFICATIVA DE NEGCIO

4.3.1 Responsabilidades do Dono do Produto na Justificativa de Negcio

A responsabilidade de priorizar e entregar o valor do negcio em uma organizao, para projetos,


principalmente do Dono do Produto. Para programas e portflios, a responsabilidade respectivamente do,
Dono do Produto do Programa e do Dono do Produto do Portflio. O seu papel atuar como representante
efetivo do cliente e/ou patrocinador. As orientaes para avaliar e mensurar o valor do negcio, podem
normalmente ser estabelecidas pelo Scrum Guidance Body.

A figura 4-2 ilustra as responsabilidades da justificativa de negcio em uma ordem hierrquica.

Entregar valor para os portflios


Criar a justificativa de negcio para os portflios
Dono do Produto
Fornecer orientao a valor para programas
do Portflio Aprovar a justificativa de negcio para os
programas
Entregar valor para os programas
Criar a justificativa de negcio para os
Dono do Produto
programas
do Programa Fornecer orientao a valor para projetos
Aprovar a justificativa de negcio para os projetos
Entregar valor para os projetos
Criar a justificativa de negcio para os projetos
Dono do Produto
Confirmar a realizao de benefcios para os
stakeholders

Figura 4-2: A Hierarquia de Responsabilidades da Justificativa de Negcios

4.3.2 Responsabilidades de outros Papis do Scrum na Justificativa de


Negcios

importante observar que, embora o Dono do Produto seja o responsvel principal pela justificativa de
negcio, outras pessoas que trabalham em projetos Scrum tambm contribuem significativamente, como:

1. O patrocinador fornece recursos para o projeto e o monitora constantemente, para confirmar a


realizao de benefcios.

2. Os clientes e usurios que esto envolvidos na definio da lista de prioridades de requisitos e


Estrias de Usurio no Backlog Priorizado do Produto, revisando as entregas aps cada Sprint ou
Release, e confirmando a realizao dos benefcios.

68 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

3. O Scrum Guidance Body que pode fornecer orientaes e recomendaes relacionadas com as
tcnicas de justificativa de negcio, confirmar a realizao de benefcios, e assim por diante. Tais
orientaes e recomendaes podem ser referenciadas pelo Time Central do Scrum e
Stakeholders.

4. O Scrum Master que facilita a criao de entregas do projeto; gerencia os riscos, mudanas e
impedimentos, durante a Reunio Diria, Retrospectiva do Sprint, e outros processos do Scrum. O
Scrum Master coordena com o Time Scrum, com o Dono do Produto e outros stakeholders, a
criao de entregas para garantir que os benefcios do projeto sejam realizados.
4
5. O Time Scrum que trabalha na criao das entregas do projeto e contribui para realizar o valor do
negcio, para todos os stakeholders e para o projeto. O Time Scrum tambm est envolvido em:
Desenvolver os pico(s); Criar o Backlog Priorizado do Produto; Criar as Estrias de Usurio;
Aprovar, Estimar, e Comprometer as Estrias de Usurio; e em processos associados, onde os
requisitos de negcios so definidos e priorizados. O Time Scrum ainda ajuda na identificao de
riscos, e envia Solicitaes de Mudana para melhorias, durante as Reunies de Retrospectiva do
Sprint entre outras reunies.

4.4 Importncia da Justificativa de Negcio


A justificativa de negcio demonstra as razes para a realizao de um projeto, respondendo pergunta:
"Por que este projeto necessrio?". A justificativa de negcio impulsiona toda a tomada de deciso
referente a um projeto. Por isso, importante avaliar a sua viabilidade e probabilidade de sucesso, no
apenas antes de se comprometer com despesas significativas ou investimentos iniciais, mas tambm
durante todo o ciclo de vida do projeto, atravs da verificao da justificativa de negcio. Um projeto deve
ser suspenso se for considerado invivel, e esta deciso deve partir dos stakeholders e da alta gerncia. A
justificativa de negcio deve ser avaliada no incio do projeto, em intervalos pr-definidos, ou a qualquer
momento, caso ocorra o surgimento de problemas maiores ou de riscos que ameacem a viabilidade do
projeto.

4.4.1 Os Fatores usados para Determinar a Justificativa de Negcio

Existem inmeros fatores que o Dono do Produto deve considerar ao determinar a justificativa de negcio
para um projeto. A seguir, alguns dos fatores mais importantes:

1. Justificativa do Projeto

A Justificativa do projeto inclui todos os fatores que implicam o projeto, sejam esses positivos ou
negativos, escolhidos ou no (por exemplo, a capacidade insuficiente para atender a demanda
existente e prevista, a diminuio da satisfao dos clientes, lucros baixos, exigncia legal etc).

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 69


4 JUSTIFICATIVA DE NEGCIO

2. Necessidades do Negcio

As necessidades do negcio so os resultados de negcios que o projeto dever cumprir,


conforme documentado na Declarao da Viso do Projeto.

3. Benefcios do Projeto

Os Benefcios do Projeto incluem todas as melhorias mensurveis em um produto, servio ou


resultado que possam ser fornecidas na concluso bem sucedida de um projeto.

4. Custo de Oportunidade

O custo de oportunidade refere-se ao valor da prxima melhor opo de negcio ou projeto, que foi
descartado em favor do projeto escolhido.

5. Riscos Maiores

Os riscos incluem eventos incertos ou no planejados que podem afetar a viabilidade e potencial
de sucesso do projeto.

6. Prazos do Projeto

Os Prazos refletem o tamanho ou a durao de um projeto e incluem o tempo durante o qual os


benefcios do projeto sero realizados.

7. Custos do Projeto

Os Custos do Projeto so investimentos e outros custos de desenvolvimento de um projeto.

4.4.2 Justificativa de Negcio e o Ciclo de Vida do Projeto

A justificativa de negcio avaliada primeiramente antes do incio de um projeto, e continuamente


verificada ao longo de seu ciclo de vida. Os passos seguintes mostram como a justificativa de negcio
determinada:

1. Avaliar e Apresentar um Caso de Negcio

A justificativa de negcio de um projeto normalmente analisada e confirmada pelo Dono do


Produto. Sendo esta, documentada e apresentada na forma de Caso de Negcio do projeto, antes
da fase inicial, envolvendo a considerao de vrios fatores especificados na seo 4.4.1. Uma vez
documentada, o Dono do Produto deve criar a Declarao da Viso do Projeto, e obter a
aprovao dos principais tomadores de decises da organizao. Geralmente, este grupo
composto por executivos e/ou alguma forma de conselho administrativo do projeto ou do programa.

70 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

2. Justificativa de Valor Contnuo

Uma vez que os tomadores de decises aprovam a Declarao da Viso do Projeto, esta ento,
torna-se a base para a criao da justificativa de negcio. A justificativa de negcio validada ao
longo da execuo do projeto, geralmente em intervalos ou marcos pr-definidos, como durante,
reunies de portflio, programa e de Reviso do Backlog Priorizado do Produto, ou quando so
identificados problemas maiores, ou riscos que ameacem a viabilidade do projeto. Isso pode
acontecer em vrios processos Scrum, incluindo a Reunio Diria e o Refinamento do Backlog
Priorizado do Produto. Ao longo do projeto, o Dono do Produto deve manter a justificativa de
negcio atualizada na Declarao da Viso do Projeto, com informaes relevantes ao projeto,
para permitir que os tomadores de decises continuem a tomar decises informadas. 4

3. Confirmar a Realizao de Benefcios

O Dono do Produto confirma a realizao dos benefcios organizacionais ao longo do projeto, bem
como aps a concluso das Estrias de Usurio no Backlog Priorizado do Produto. Os benefcios
de projetos Scrum so realizados durante os processos de Demonstrar e Validar o Sprint,
Retrospectiva do Sprint, Envio de Entregveis e Retrospectiva Projeto.

A figura 4-3 resume as etapas que determinam a justificativa de negcio.

Figura 4-3: A Justificativa de Negcio e o Ciclo de Vida do Projeto

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 71


4 JUSTIFICATIVA DE NEGCIO

4.5 Tcnicas da Justificativa de Negcio


As sees a seguir tratam de algumas das ferramentas utilizadas para analisar e avaliar a justificativa de
negcio, bem como alguns outros aspectos relacionados com a justificativa e seleo de projetos. No
necessrio, e nem mesmo recomendado a utilizao de todas as tcnicas disponveis, em cada projeto.
Algumas tcnicas no so adequadas dependendo do projeto em especfico, e as tcnicas podem ser
utilizadas para avaliar os projetos individualmente, ou para comparar o valor esperado de vrios projetos.

O Scrum Guidance Body (SGB), que pode ser um grupo de especialistas, ou um conjunto de documentos
sobre as normas e procedimentos organizacionais, define as diretrizes e medidas que sero utilizadas para
avaliar o valor do negcio. Cada Dono do Produto , no entanto, responsvel por executar as atividades
que verificam e acompanham o valor de negcio para seus respectivos projetos, programas ou portflios.

4.5.1 Estimativa do Valor do Projeto

O valor a ser fornecido por projetos de negcio, pode ser estimado utilizando vrios mtodos, tais como:
Retorno sobre Investimento (ROI), Valor Presente Lquido (VPL) e Taxa Interna de Retorno (TIR).

1. Retorno sobre Investimento (ROI)

O Retorno sobre Investimento (ROI), quando usado na justificativa do projeto, avalia o lucro lquido
esperado a ser alcanado por um projeto. calculado a partir da deduo do investimento ou
custos esperados em um projeto sobre o seu retorno e, em seguida, dividindo esse lucro lquido,
pelos custos esperados, a fim de se obter uma taxa de retorno. Outros fatores como as taxas de
inflao e de juros sobre o dinheiro emprestado podem ser considerados durante os clculos de
ROI.

Frmula ROI:

ROI = (Receita do Projeto Custo do Projeto) / Custo do Projeto

Exemplo: O ROI de um projeto que vai custar R$ 125.000,00 para ser desenvolvido, com
benefcios financeiros esperados estimados em R$ 300.000,00 calculado da seguinte forma:

ROI = (R$300.000,00 - R$125.000,00) / R$125.000,00 = 1.4

Portanto, o ROI de 1,4 vezes o investimento (ou 140%).

O incremento frequente de produtos ou de servios, um fundamento essencial do Scrum,


permitindo a verificao antecipada do ROI. Isso ajuda na avaliao da justificativa de valor
contnuo.

72 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

2. Valor Presente Lquido (VPL)

O Valor Presente Lquido (VPL) um mtodo utilizado para determinar o valor lquido atual de um
benefcio financeiro futuro, assumindo-se inflao ou taxa de juros. Em outras palavras, o VPL o
valor total esperado da renda ou da receita de um projeto, menos o total do custo previsto, levando
em conta valor do dinheiro no tempo.

Exemplo: Considerando-se o VPL como um critrio de seleo, qual seria a melhor escolha
entre as opes abaixo?
4
O projeto A tem um VPL de R$1.500,00 e ser finalizado em 5 anos.
O projeto B tem um VPL de R$1.000,00 e ser finalizado em 1 ano.

Soluo: Projeto A, porque o seu VPL maior; o fato de que o Projeto B tem uma durao mais
curta do que o Projeto A no considerado aqui, porque o tempo j est sendo contabilizado
nos clculos do VPL, ou seja, o valor atual que est sendo considerado no clculo e no o
futuro.

3. Taxa Interna de Retorno (TIR)

A Taxa Interna de Retorno uma taxa de desconto de um investimento em que o valor presente do
fluxo de caixa, considerado igual ao valor presente das sadas de caixa, para avaliar a taxa de
retorno de um projeto. Ao comparar os projetos, o que tiver o TIR maior tipicamente melhor.

Embora a TIR no seja utilizada frequentemente para justificar projetos, o que ocorre com algumas
outras tcnicas, tais como o VPL, importante ter o conhecimento desse conceito.

Exemplo: Baseando-se na TIR, qual projeto mais desejvel?

O projeto A, que tem uma TIR de 15% e ser concludo em 5 anos.


O projeto B, que tem uma TIR de 10% e ser concluda em 1 ano.

Soluo: o Projeto A, j que sua TIR maior. O fato de que o Projeto B tem uma durao
menor do que o projeto A, no considerado aqui, porque o tempo j levado em conta nos
clculos TIR, ou seja, como no VPL, o valor atual que est sendo considerado no clculo
para determinar a TIR, e no o futuro.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 73


4 JUSTIFICATIVA DE NEGCIO

4.5.2 Planejamento para o Valor

Aps justificar e confirmar o valor do projeto, o Dono do Produto deve considerar as polticas,
procedimentos, modelos e as normas gerais organizacionais estabelecidas pelo Scrum Guidance Body (ou
conselhos organizacionais para projetos semelhantes) no planejamento de um projeto; ao mesmo tempo
em que maximiza a Entrega Orientada a Valor. O nus para determinar como o valor criado recai sobre
os stakeholders (patrocinadores, clientes e/ou usurios), enquanto que o Time Scrum se concentra no que
ser desenvolvido. Algumas das ferramentas comuns recomendados pelo Scrum Guidance Body podem
incluir:

1. Mapeamento do Fluxo de Valor

O Mapeamento do Fluxo de Valor utiliza fluxogramas para ilustrar o fluxo de informaes


necessrias para concluir um processo. Esta tcnica pode ser usada para simplificar o processo,
ajudando a determinar elementos que no agregam valor.

2. Priorizao Baseada em Valor para o Cliente

A Priorizao Baseada em Valor para o Cliente, d importncia prioritria para o cliente, e se


esfora para implementar em primeiro lugar as Estrias de Usurio com o valor mais alto. Esses
valores so identificados e movidos para o topo do Backlog Priorizado do Produto.

O time pode usar uma variedade de esquemas de priorizao para determinar as caractersticas de
alto valor.

a. Esquemas Simples

O Esquemas Simples envolvem a rotulagem de itens, como: prioridade "1", "2", "3" ou
"Alta", "Mdia" e "Baixa" e assim por diante. Embora esta seja uma abordagem simples e
direta, ela pode tornar-se problemtica, porque muitas vezes h uma tendncia a rotular
tudo como: prioridade "1" ou "Alta". Mesmo esquemas de priorizao Alta, Mdia, e
Baixa podem encontrar dificuldades semelhantes.

b. Priorizao MoSCoW

O seu nome deriva das primeiras letras das palavras Must have (deve ter), Should have
(deveria ter), Could have (poderia ter), e Wont have (no vai ter). Este mtodo de
priorizao geralmente mais eficaz do que o de esquemas simples. Os rtulos esto em
ordem de prioridade decrescente, com, "deve ter" sendo aquelas caractersticas que sem
as quais o produto no ter valor, e, "no ter" sendo aquelas caractersticas que embora
seria bom ter, sua incluso no necessria.

c. Dinheiro Monopoly

Essa tcnica consiste em dar ao cliente "dinheiro monopoly" ou "dinheiro falso", igual ao
montante do oramento do projeto e pedindo-lhes para distribu-lo entre as Estrias de

74 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

Usurio em questo. Desta forma, o cliente vai priorizar com base no que eles esto
dispostos a pagar por cada Estria de Usurio.

d. Mtodo de Ponto-100

O Mtodo de Ponto-100 foi desenvolvido por Dean Leffingwell e Don Widrig (2003). Trata-
se de dar ao cliente 100 pontos que ele poder usar para votar nas caractersticas que
considerar mais importante.

e. Anlise de Kano

A Anlise de Kano foi desenvolvida por Noriaki Kano (1984), com base nas preferncias 4
dos clientes, esta anlise envolve a classificao de caractersticas ou requisitos em
quatro categorias:

Caractersticas que se no estiverem presentes, so suscetveis a fazer com que o cliente


no goste do produto. Porm no afetam o nvel de satisfao se estiverem presentes

1. Excitantes/Prazerosos: Recursos novos ou de alto valor para o cliente


2. Satisfatrios: Recursos que oferecem valor para o cliente
3. Insatisfatrios: Recursos que, se no estiverem presentes, podem fazer com que o
cliente no goste do produto, mas se estiverem presentes no afetam o nvel de
satisfao
4. Indiferentes: Recursos que no afetam o cliente de nenhuma maneira e devem ser
eliminados

A figura 4-4 retrata uma ilustrao da Anlise de Kano.

Figura 4-4: Anlise de Kano

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 75


4 JUSTIFICATIVA DE NEGCIO

Curiosamente ao longo do tempo, os recursos normalmente caem na lista de classificao;


os clientes esperam recursos (por exemplo, cmeras em celulares) e esses recursos vo
deixar de ser Excitantes/Prazerosos e passaram a ser Satisfatrios e, eventualmente, a
serem Insatisfatrios.

4.5.3 Ranking Relativo de Priorizao

Uma lista simples de Estrias de Usurio em ordem de prioridade, um mtodo eficaz para determinar as
Estrias de Usurio desejadas para cada iterao ou para o lanamento do produto ou servio. Seu
propsito criar uma lista simples, nica, com o objetivo de priorizar recursos, ao invs de se distrair com
vrios esquemas de priorizao.

Esta lista simples, tambm fornece uma base para a incorporao de mudanas e identificao de riscos
quando necessrio. Cada mudana ou risco identificado pode ser inserido na lista, com base em sua
prioridade com relao s outras Estrias de Usurios. Normalmente, as novas mudanas sero includas
em detrimento de recursos que foram atribudos uma prioridade mais baixa.

Definir o Minimal Marketable Feature MMF (basicamente as Caractersticas Mnimas Comerciveis)


extremamente importante durante este processo, para que o primeiro lanamento ou iterao possa
acontecer o mais cedo possvel, o que gera um aumento do ROI. Normalmente, essas Estrias de Usurios
seriam classificadas com alto nvel de prioridade.

4.5.4 Mapa da Estria

O Mapa da Estria uma tcnica que fornece um esboo visual do produto e de seus componentes
fundamentais. Formulado por Jeff Patton (2005), comumente usado para ilustrar roadmaps de produtos.
Os Mapas da Estria mostram a sequncia de iteraes de desenvolvimento de produtos, e mapeam os
recursos que sero includos em cada lanamento.

4.6 Justificativa de Valor Contnuo


O valor do negcio deve ser avaliado regularmente, para determinar se a justificativa ou viabilidade de
execuo do projeto continua a existir. A avaliao frequente do investimento no projeto em relao ao
valor do negcio que est sendo criado, qualifica a viabilidade de um projeto. Os requisitos esperados do
projeto podem mudar com frequncia, o que pode afetar tanto o investimento do projeto quanto a criao de
valor. Um aspecto chave do Scrum a sua capacidade de adaptao rpida ao caos criado por um modelo
de negcios em mutao constante. O Scrum oferece vantagens considerveis em relao a outros
modelos de desenvolvimento, em projetos com requisitos de usurios ambguos e com potencial
significante de mudanas frequentes.

76 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

O acompanhamento da taxa de entrega de valor um requisito importante para os projetos do Scrum.


Devendo ser realizado periodicamente, juntamente com a elaborao de relatrios com informaes sobre
a criao de valor, auxiliando na avaliao do status do projeto e fornecendo informaes importantes para
o cliente e outros stakeholders.

4.6.1 Anlise de Valor Agregado

Embora comumente utilizadas, as ferramentas como grficos de barra e Grficos de Gantt, tm limitaes
ao acompanhar e fornecer relatrios de progresso, referentes ao desempenho do projeto. A Anlise de
Valor Agregado (AVA) utilizada para esse propsito.
4
A AVA analisa o desempenho real do projeto em relao ao desempenho planejado em um determinado
ponto. O plano base do projeto inicial deve ser preciso para que as tcnicas de acompanhamento sejam
eficazes. A AVA frequentemente utiliza grficos e outros recursos visuais (por exemplo, a curva-S), como
forma de descrever as informaes de status do projeto.

A Anlise de Valor Agregado mede as variaes atuais no cronograma, de custo de desempenho, e prev o
custo final do projeto, com base no desempenho atual determinado. A AVA normalmente feita no final de
cada Sprint aps a concluso das Estrias de Usurio no Backlog do Sprint.

A tabela 4-1 resume as frmulas utilizadas na Anlise de Valor Agregado.

Definio do Termo Sigla Frmula


Valor Planejado VP
Valor Agregado VA
Custo Real CR
Oramento No Trmino ONT
Variao do Cronograma VCR VA - VP
Variao de Custo VC VA - CR
ndice de Desempenho Para Trmino IDPT VA / VP
ndice de Desempenho de Custo IDC VA / CR
Porcentagem Concluda % Concluda (VA / ONT) x 100
Estimativa No Trmino
1. Estimativa de suposies invlidas 1. CR + EPT
ENT
2. As variaes atuais so atpicas 2. CR + ONT - VA
3. As variaes atuais so tpicas 3. ONT / IDC
Estimativa Para Terminar EPT ENT - CR
Variao No Trmino VNT ONT - EAC

Tabela 4-1: Frmulas de Valor Agregado

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 77


4 JUSTIFICATIVA DE NEGCIO

Exemplo: Um website com 4.000 pginas precisa ser desenvolvido, assumindo-se que cada pgina da web
leva o mesmo tempo para ser concluda, e que cada pgina uma Estria de Usurio nica, com a mesma
prioridade no Backlog Priorizado do Produto. O custo estimado de concluso do projeto de R$400,000.00 e
o prazo para o projeto de 12 meses. Aps 6 meses, foram gastos R$300,000.00 e o trabalho realizado foi o
de 1.000 pginas da web.

Que informaes possumos?


Oramento No Trmino (ONT) = R$400,000.00 (Custo da linha de base para o projeto)
Valor Planejado (VP) = R$200,000.00 (j que foi planejado a concluso de 2.000 pginas da
web)
Valor Agregado (VA) = R$100,000.00 (valor de equivalente a 1.000 pginas da web concludas)
Custo Real (CR) = R$300,000.00 (o que foi gasto at agora)

Dados da curva-S:

Frmulas:
Variao do Cronograma (VCR) = VA - VP = R$100,000.00 - R$200,000.00 = - R$100,000.00
Variao de Custo (VC) = VA - CR = R$100,000.00 - R$300,000.00 = - R$200,000.00
o As variaes negativas do projeto, indicam que o valor est acima do que foi orado e que
existe atraso no cronograma.
ndice de Desempenho Para Trmino (IDPT) = VA / VP = R$100,000.00 / R$200,000.00 = 0,5
o IDPT < 1 indica que o trabalho realizado at agora foi de apenas 50% do planejado para 6
meses.
ndice de Desempenho de Custo (IDC) = VA / CR = R$100,000.00 / R$300,000.00 = 0,33
o IDC < 1 indica que para a quantidade de dinheiro gasta, apenas 33% do trabalho foi
concludo.
Porcentagem Concluda = VA / ONT x 100 = R$100,000.00 / R$400,000.00 x 100 = 25%
o Neste momento, foi concludo 25% do trabalho do projeto.

78 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

4.6.2 Diagrama de Fluxo Cumulativo (DFC)

Um Diagrama de Fluxo Cumulativo (DFC) uma ferramenta til na elaborao de relatrios e


acompanhamento de desempenho do projeto. Ele fornece uma representao visual simples do andamento
do projeto, em um determinado ponto. normalmente usado para fornecer um status de nvel superior de
todo o projeto, e no de atualizaes dirias para Sprints individuais.

A figura 4-5 um exemplo de um DFC para um projeto grande. Onde se mostram as Estrias de Usurio
que ainda no foram criadas, as que esto em processo de criao, e as que j foram criadas. Se as
necessidades dos clientes mudarem, ocorre uma mudana nas Estrias de Usurio Cumulativas que devem
ser entregues. Os pontos de mudana 1 e 2, esto no lugar onde o Dono do Produto removeu as Estrias
4
de Usurio existentes no Ajuste de Risco no Backlog Priorizado do Produto e os pontos de mudana 3 e 4
esto no lugar onde o Dono do Produto adicionou Estrias de Usurio no Ajuste de Risco no Backlog
Priorizado do Produto.

Este tipo de diagrama pode ser uma tima ferramenta para se identificar obstculos e gargalos de
processos. Por exemplo, se o diagrama mostra uma coluna que est se tornando mais estreita, enquanto
que a coluna anterior est se tornando mais larga ao longo do tempo, pode haver um gargalo, e mudanas
podem ser necessrias para aumentar a eficincia e/ou melhorar o desempenho do projeto.

Figura 4-5: Exemplo do Diagrama de Fluxo Cumulativo (DFC)

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 79


4 JUSTIFICATIVA DE NEGCIO

4.7 Confirmar a Realizao de Benefcios


Ao longo de um projeto, importante verificar se os benefcios esto sendo realizados. Independentemente
dos produtos de um projeto Scrum serem tangveis ou intangveis, tcnicas adequadas de verificao so
necessrias para confirmar que o time est criando os resultados que iro atingir os benefcios e valor
definidos no incio do projeto.

4.7.1 Prottipos, Simulaes e Demonstraes

Demonstrar prottipos para os clientes e simular suas funcionalidades, so tcnicas comumente usadas
para confirmar o valor.

Muitas vezes, aps a demonstrao ou utilizao dos recursos, os clientes podem determinar mais
claramente se os mesmos so adequados as suas necessidades. Eles podem perceber a necessidade de
recursos adicionais, ou podem decidir modificar os requisitos de recursos previamente definidos. No
desenvolvimento de produtos, esta experincia do cliente passou a ser conhecida como IKIWISI (Ill Know It
When I See It, ou seja, eu vou saber quando v-lo).

Atravs de demonstraes, ou de acesso a iteraes iniciais, os clientes tambm podem avaliar at que
ponto o time interpretou com sucesso as suas necessidades e satisfez as suas expectativas.

80 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


4 JUSTIFICATIVA DE NEGCIO

4.8 Resumo das Responsabilidades

Papis Responsabilidades

Estabelecer diretrizes e medidas gerais para avaliar o valor


Scrum Guidance
Atuar como um consultor e fornece orientao para projetos, programas e
Body
portflios, conforme exigido

Garanir a entrega de valor para os portflios


Dono do Produto do Criar a justificativa de negcio para os portflios
Portflio Fornecer a orientao de valor para programas dentro do portflio
4
Aprovar a justificativa de negcio de programas dentro do portflio
Scrum Master do Garantir que os resultados desejados do portflio sejam alcanados
Portflio Realizar a Justificativa de Valor Contnuo para o portflio
Garantir a entrega de valor para os programas
Dono do Produto do Criar a justificativa de negcio para os programas
Programa Fornecer a orientao de valor para projetos dentro do programa
Aprovar a justificativa de negcio de projetos dentro do programa

Garantir que os resultados desejados do programa sejam comunicados e


Scrum Master do
entendidos
Programa
Realizar a Justificativa de Valor Contnuo para o programa

Ajudar a priorizar as Estrias de Usurio e os requisitos no Backlog Priorizado


do Produto
Stakeholder(s)
Comunicar-se com o Time Scrum e confirma a realizao do valor, no final de
cada Sprint, Release, e do projeto
Garantir a entrega de valor para os projetos
Dono do Produto Manter a justificativa de negcio para projetos
Confirmar e comunicar os benefcios do projeto aos stakeholders

Garantir que os resultados desejados do projeto sejam comunicados e


Scrum Master commpreendidos pelo Time Scrum
Realizar a Justificativa de Valor Contnuo para os projetos

Garantir que as entregas do projeto sejam concludas de acordo com os


Time Scrum Critrios de Aceitao acordados
Realizar a Justificativa de Valor Contnuo para os projetos

Tabela 4-2: Resumo das Responsabilidades Relevantes a Justificativa de Negcio

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 81


4 JUSTIFICATIVA DE NEGCIO

4.9 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


Os projetos tradicionais enfatizam um planejamento inicial extenso e a adeso ao plano de projeto, criado
pelo gerente de projeto. Normalmente, as mudanas so gerenciadas atravs de um sistema formal de
gerenciamento de mudana, e o valor criado no final do projeto, quando o produto final entregue.

Em projetos Scrum, no feito um planejamento de longo prazo extenso antes da execuo do projeto. O
planejamento feito de forma iterativa, antes de cada Sprint. Isto permite uma resposta rpida e eficaz s
mudanas, o que resulta em custos mais baixos e, finalmente, aumento da margem de lucros e de Retorno
sobre Investimento (ROI). Alm disso, a Entrega Orientada a Valor (seo 4.3), um dos principais
benefcios do framework Scrum, fornecendo uma priorizao melhor, e a realizao do valor do negcio de
uma maneira mais rpida. Devido natureza interativa do desenvolvimento do Scrum, h pelo menos
sempre uma verso disponvel do produto de acordo com o Minimal Marketable Feature MMF
(Caractersticas Mnimas Comerciveis). Mesmo se um projeto for finalizado, geralmente existem alguns
benefcios ou valor criado antes de sua resciso.

82 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

5. QUALIDADE

5.1 Introduo
O objetivo deste captulo definir a qualidade no que se refere aos projetos e apresentar a abordagem do
Scrum no atingimento de nveis exigidos de qualidade.

Qualidade, como definido no Guia para o Conhecimento em Scrum (Guia SBOK) aplicvel a:

Portflio, programas e/ou projetos em qualquer indstria


5
Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode se referir a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Este captulo est dividido nas seguintes sees:

5.2 Guia de PapisEsta seo fornece orientao sobre quais sees so relevantes para cada papel do
Scrum: Dono do Produto, Scrum Master, e Time Scrum.

5.3 Definio de QualidadeEsta seo apresenta a definio de Scrum sobre qualidade, com uma
distino clara do escopo, e descreve a relao entre a qualidade e o valor de negcio.

5.4 Critrios de Aceitao e o Backlog Priorizado do ProdutoEsta seo enfatiza a importncia dos
Critrios de Aceitao, e do Backlog Priorizado do Produto, e sua relao. Ele tambm explica a definio
de Scrum de Pronto.

5.5 Gerenciamento de Qualidade em ScrumEsta seo fornece detalhes no contexto do Scrum sobre:
o planejamento de qualidade, controle de qualidade e garantia de qualidade.

5.6 Resumo das ResponsabilidadesEsta seo descreve as responsabilidades relevantes de qualidade


para cada pessoa ou papel em um projeto.

5.7 Scrum x O Modelo Tradicional de Gerenciamento de ProjetoEsta seo destaca os benefcios do


gerenciamento de qualidade no mtodo Scrum em relao aos modelos tradicionais de gerenciamento de
projetos.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 83


5 QUALIDADE

5.2 Guia dos Papis


1. Dono do ProdutoA leitura completa deste captulo importante para qualquer pessoa que esteja
assumindo o papel de Dono do Produto em projetos Scrum.

2. Scrum MasterO Scrum Master tambm deve estar familiarizado com este captulo inteiro, com
foco principal nas sees 5.3 e 5.4, 5.5.3 e 5.6.

3. Time Scrum O Time Scrum devem se concentrar principalmente nas sees 5.3 e 5.4, e 5.6.

5.3 Definio de Qualidade


Existem inmeras maneiras de se definir qualidade.

Em Scrum, a qualidade definida como a capacidade dos produtos ou entregas concludas em atender os
Critrios de Aceitao e em alcanar o valor de negcio esperado pelo cliente.

Para garantir que um projeto satisfaa os requisitos de qualidade, o Scrum adota uma abordagem de
Melhoria Contnua em que o time aprende com a experincia e engajamento dos stakeholders, a manter
constantemente atualizado o Backlog Priorizado do Produto com qualquer mudana nos requisitos. O
Backlog Priorizado do Produto apenas ser concludo no encerramento ou trmino do projeto. Qualquer
alterao nos requisitos reflete em mudanas no ambiente de negcio, interno ou externo, permitindo que o
time trabalhe e adapte continuamente para atingir esses requisitos.J que o Scrum exige que o trabalho
seja feito em incrementos ao longo dos Sprints, isso faz com que os erros ou defeitos sejam notados mais
cedo, atravs de repetitivos testes de qualidades, ao invs de quando o produto final ou servio est quase
concludo. Alm disso, as tarefas importantes relacionadas com a qualidade (por exemplo,
desenvolvimento, testes e documentao) so completadas pelo mesmo time, como parte do mesmo
Sprint. Isso garante que a qualidade seja inerente a qualquer entregvel Pronto criado como parte de um
Sprint. Portanto, a Melhoria Contnua com testes repetitivos otimiza a probabilidade de atingir os nveis de
qualidade esperados em um projeto Scrum. As discusses constantes entre o Time Central de Scrum e os
stakeholders (incluindo cliente e usurios), com relao aos incrementos reais do produto a serem
entregues ao final de cada Sprint, garantem que a diferena entre os resultados reais produzidos durante o
projeto, e as expectativas dos clientes com relao ao mesmo sejam constantemente reduzidas.

84 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

5.3.1 Qualidade e Escopo

Em um projeto Scrum os requisitos de escopo e qualidade so determinados levando-se em considerao


vrios fatores, como:

O projeto vai atender as necessidades do negcio


A capacidade e disposio da organizao para atender a necessidade do negcio identificadas
As necessidades atuais e futuras do pblico-alvo

O Escopo de um projeto a soma total de todos os incrementos do produto e do trabalho necessrio para o
desenvolvimento do produto final. A qualidade a capacidade das entregas em atender os requisitos de
qualidade do produto e satisfazer as necessidades dos clientes. Em Scrum, o escopo e qualidade do
projeto so capturados no Backlog Priorizado do Produto, e o escopo de cada Sprint determinado pelo
5
refinamento de Itens grandes no Backlog Priorizado do Produto (IBPs), transformando-os em um conjunto
de pequenas, porm detalhadas, Estrias de Usurio que podem ser planejadas, desenvolvidas e
verificadas dentro de um Sprint.

O Backlog Priorizado do Produto continuamente refinado pelo Dono do Produto. O Dono do Produto
garante que quaisquer Estrias de Usurio, que espera-se que o Time Scrum conclua em um Sprint, sejam
refinadas antes do incio do Sprint. Em geral, os requisitos mais importantes na resoluo de problemas de
clientes, ou para satisfazer suas necessidades so priorizados como de alto nvel e os restantes recebem
uma classificao de baixo nvel. As Estrias de Usurio de menor importncia so desenvolvidas em
Sprints subsequentes, ou podem ainda, serem deixadas de fora dependendo das necessidades do cliente.
Durante a execuo do Sprint, o Dono do Produto, o cliente, e o Time Scrum, podem discutir sobre a lista
de caractersticas do produto, para atender as necessidades de mudanas solicitadas pelo clientes.

5.3.2 Qualidade e Valor de Negcio

A qualidade e o valor de negcio esto muito ligados. Compreender o escopo de um projeto fundamental
para mapear corretamente os benefcios e resultados do projeto e de seu produto final, para entregar valor
de negcio. Para determinar o valor de negcio de um produto, importante entender a necessidade de
negcio que impulsiona os requisitos do produto. Sendo assim, a necessidade de negcio determina o
produto desejado, e o produto, por sua vez, fornece o valor de negcio esperado.

A qualidade uma varivel complexa. Um aumento no escopo, sem o respectivo aumento de tempo ou de
recursos, tende a reduzir a qualidade. Do mesmo modo que, uma reduo de tempo ou de recursos, sem
diminuir o escopo, tambm geralmente resulta na diminuio de qualidade. O Scrum acredita na
manuteno de um ritmo sustentvel de trabalho, o que ajuda a melhorar a qualidade a longo prazo.

O Scrum Guidance Body pode definir os padres exigidos e os requisitos mnimos de qualidade para todos
os projetos na organizao. Estes padres devem ser seguidos por todos os Times Scrum na empresa.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 85


5 QUALIDADE

5.4 Critrios de Aceitao e Backlog Priorizado do Produto


O Backlog Priorizado do Produto um documento de requisitos individuais que definem o escopo do
projeto, fornecendo uma lista de prioridades das caractersticas do produto ou servio a serem entregues
pelo projeto. Os recursos necessrios so descritos na forma de Estrias de Usurio. As Estrias de
Usurio so requisitos especficos descritos por vrios stakeholders, no que refere-se ao produto ou servio
proposto. Cada Estria de Usurio ter respectivamente os Critrios de Aceitao da Estria de Usurio
associados (tambm conhecidos como "Critrios de Aceitao"), que so os objetivos componentes pelos
quais a funcionalidade de uma Estria de Usurio julgada. Os Critrios de Aceitao so desenvolvidos
pelo Dono do Produto de acordo com seu conhecimento sobre os requisitos do cliente. O Dono do Produto,
ento, comunica ao Time Scrum as Estrias de Usurio no Backlog Priorizado do Produto e busca-se um
acordo. Os Critrios de Aceitao devem descrever explicitamente as condies que as Estrias de Usurio
devem satisfazer. Os Critrios de Aceitao claramente definidos so muito importante para a entrega da
funcionalidade de forma eficaz e feita a tempo, definida nas Estrias de Usurio, o que em uma ltima
anlise determina o sucesso do projeto.

No final de cada Sprint, o Dono do Produto utiliza esses critrios para verificar as entregas concludas,
podendo aceitar ou rejeitar as entregas individuais e suas respectivas Estrias de Usurio. Se as entregas
forem aceitas pelo Dono do Produto, a Estria de Usurio ser considerada Pronta. fundamental que o
Time Scrum tenha uma definio clara de Pronto, para ajudar a esclarecer os requisitos e aderir a normas
de qualidade. Ajudando o time a pensar a partir da perspectiva do usurio, enquanto trabalham com as
Estrias de Usurio.

As Estrias de Usurio correspondentes a entregas rejeitadas, so novamente adicionadas ao Backlog do


Produto Priorizado e Atualizado, durante o processo de Refinamento do Backlog Priorizado do Produto,
para serem concludas em Sprints futuros. A rejeio de algumas entregas individuais e suas Estrias de
Usurio correspondentes, no significa a rejeio do produto ou incremento do produto final. O produto ou
incremento do produto poder ser potencialmente utilizvel, mesmo se algumas Estrias de Usurio forem
rejeitadas.

A figura 5-1 ilustra o conceito dos Critrios de Aceitao, juntamente com o fluxo de incremento do produto.

86 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

Figura 5-1: Diagrama de Fluxo de Incremento do Projeto

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 87


5 QUALIDADE

5.4.1 Escrevendo os Critrios de Aceitao

Os Critrios de Aceitao so nicos para cada Estria de Usurio e no so um substitutos na lista de


requisitos.

Exemplo:

Persona: Janine tem 36 anos, uma profissional casada, com uma famlia de trs filhos. Ela uma mulher ocupada,
bem sucedida e que equilibra sua vida profissional e pessoal. Ela se sente confortvel com a tecnologia, e adota
servios e produtos inovadores. Est sempre conectada internet atravs de mltiplos dispositivos, e regularmente
faz compras on-line.

Estria de Usurio: Janine - Como cliente on-line de supermercado, eu deveria ser capaz de salvar e ver o esboo
do meu pedido utilizando qualquer um dos meus dispositivos, para que eu possa finalizar o processo de encomenda
quando eu desejar.

Critrios de Aceitao:

Cada pedido em andamento deve ser salvo como esboo do pedido, a cada 5 segundos para a conta do
usurio conectado
Novos esboos de pedidos devem aparecer como notificaes em qualquer dispositivo em que o usurio
fizer o login

importante para o Dono do Produto notar que as Estrias de Usurio que atenderem a maioria, mas no
todos, os Critrios de Aceitao no podem ser aceitas como Prontas. Os projetos Scrum atuam em Sprints
Time-boxed, com um Backlog do Sprint dedicado para cada Sprint. Muitas vezes, a ltima parte do trabalho
pode ser a parte mais complicada de uma Estria de Usurio, e pode levar mais tempo do que o esperado.
Se as Estrias de Usurio incompletas receberam crdito parcial como Prontas, e transitarem para o
prximo Sprint, ento o progresso do Sprint posterior poder ser interrompido. Portanto, o status Pronto
preto no branco. A Estria de Usurio s pode ser Pronta ou no Pronta.

5.4.2 Os Critrios Mnimos de Aceitao

A unidade de negcios de nvel superior pode anunciar Critrios Mnimos de Aceitao obrigatrios, que
ento passam a fazer parte dos Critrios de Aceitao para qualquer Estria de Usurio dessa unidade de
negcios. Qualquer funcionalidade definida pela unidade de negcios deve satisfazer esses Critrios
Mnimos de Aceitao, se for para ser aceito pelo respectivo Dono do Produto. A introduo deste Critrio
de Aceitao pode levar a um conjunto subsequente de Critrios de Aceitao para o portflio, programa e
projeto (veja a Figura 5-2). Os padres gerais de qualidade, diretrizes e modelos para um portflio
completo, so definidos pelo Dono do Produto do Portflio, enquanto que os Critrios Mnimos de Aceitao
para programas so definidos pelo Dono do Produto do Programa. Assim, os Critrios de Aceitao para a
Estria de Usurio em um projeto incluir implicitamente todos os Critrios Mnimos de Aceitao de nveis
mais altos, conforme cada caso.

88 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

Dono do Produto do Define os Critrios Mnimos de Aceitao para todo o portflio


Portflio Revisa as entregas do portflio

Define os Critrios Mnimos de Aceitao para todo o programa,


Dono do Produto do incluindo os Critrios de Aceitao do portflio
Programa Revisa as entregas do programa
Define os Critrios Mnimos de Aceitao para o projeto, incluindo
Dono do Produto os Critrios de Aceitao do programa
Revisa as entregas do projeto

Figura 5-2: Sequncia dos Critrios de Aceitao

Uma vez que os Critrios Mnimos de Aceitao so definidos, os mesmos podero ser registrados nos 5
documentos do Scrum Guidance Body e referido por Times Scrum conforme exigido.

5.4.3 Definio de Pronto

H uma diferena fundamental entre os "Critrios de Pronto" e os "Critrios de Aceitao". Enquanto que os
Critrios de Aceitao so exclusivos para Estrias de Usurio individuais, os Critrios de Pronto so um
conjunto de regras que so aplicveis a todas as Estrias de Usurio em um determinado Sprint. Os
Critrios de Pronto geralmente podem incluir:

avaliao por outros membros do time


Concluso do teste unitrio da Estria de Usurio
Concluso de testes de qualidade
Concluso de toda a documentao relacionada com a Estria de Usurio
Todos os problemas so corrigidos
Demonstrao bem sucedida para os stakeholders e/ou representantes do negcio

Da mesma maneira que acontece com os Critrios de Aceitao, todas as condies dos Critrios de
Pronto devem ser satisfeitas, para que a Estria de Usurio seja considerada Pronta.

O Time Scrum deve utilizar uma lista de verificao dos Critrios gerais de Pronto para garantir que uma
tarefa foi concluda e que o resultado atende a Definio de Pronto. Uma definio clara de Pronto
fundamental, pois ajuda a eliminar a ambiguidade e permite ao time aderir aos padres de qualidade
exigidos. A definio de Pronto tipicamente determinada e documentada pelo Scrum Guidance Body.

Os registros e dados para cumprir com as exigncias de requisitos de documentao do projeto, podem ser
gerados conforme o time prossegue atravs dos Sprints e das Releases.

A incluso de atividades como; a da realizao de reunies de avaliao e de escrever os documentos de


design, podem ajudar a garantir o cumprimento dos padres internos e externos de qualidade. Os princpios
bsicos do Scrum (iteraes curtas, construo incremental, envolvimento do cliente, a adaptao novos
requisitos, e constante ajuste do escopo, tempo e custo no projeto) ainda sero aplicados.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 89


5 QUALIDADE

5.4.4 Aceitao ou Rejeio dos Itens do Backlog Priorizado do Produto

Perto do final de qualquer iterao, a respectiva unidade de negcio e os stakeholders participam de uma
Reunio de Reviso do Sprint, em que o incremento do produto demonstrado para o Dono do Produto,
patrocinador, cliente e usurio. Enquanto o feedback de todos os stakeholders coletado, somente o Dono
do Produto tem o poder de aceitar ou rejeitar uma Estria de Usurio em particular, conforme acordado nos
Critrios de Aceitao. Sendo assim, o papel dos Critrios de Aceitao na manuteno da qualidade
fundamental e deve ser claramente entendido pelo time. A responsabilidade em garantir que os Critrios de
Aceitao para uma Estria de Usurio, no sejam alterados pelo Dono do Produto no meio de uma Sprint
do Scrum Master. As Estrias de Usurio, parcialmente concludas so rejeitadas e classificadas como
no Prontas e retornam para o Backlog Priorizado do Produto.

5.5 Gerenciamento de Qualidade em Scrum


O cliente o stakeholder mais importante para qualquer projeto. Portanto, importante entender as
necessidades e requisitos do cliente. A Voz do Cliente (VOC) pode ser referida como os requisitos
explcitos e implcitos do cliente, que devem ser entendidos antes da concepo de um produto ou servio.
Geralmente, em um ambiente Scrum, o foco do Dono do Produto est sobre os requisitos e objetivos de
negcios, que juntos representam a Voz do Cliente. O Dono do Produto pode beneficiar-se muito com a
orientao disponvel no Scrum Guidance Body (seja atravs de documentos de qualidade ou normas, ou
de especialistas em qualidade). Esses especialistas devem trabalhar com o Dono do Produto e com o
cliente, para garantir um nvel adequado de detalhes e informaes nas Estrias de Usurio, uma vez que
estas so a base para o sucesso de qualquer projeto Scrum.

Deve-se notar que os stakeholders externos no esto diretamente envolvidos com o Time Scrum e, em
vez disso, interagem principalmente com o Dono do Produto. Para qualquer projeto do Scrum, o cliente
pode ser um dos seguintes:

Interno (dentro da mesma organizao)


Externo (fora da organizao)

O Gerenciamento de Qualidade em Scrum permite que os clientes tornem-se cientes de quaisquer


problemas no incio do projeto, e os ajuda a reconhecer se um projeto ir ser til para eles ou no. Em
Scrum, a qualidade a satisfao do cliente, e a funcionalidade de um produto, no necessariamente
atendendo as medidas arbitrrias. Esta distino torna-se muito importante no ponto de vista do cliente,
porque eles so os que esto investindo tempo e dinheiro no projeto.

O Gerenciamento de Qualidade em Scrum facilitado por meio de trs atividades inter-relacionadas:

1. Planejamento de Qualidade
2. Controle de Qualidade
3. Garantia de Qualidade

90 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

5.5.1 Planejamento de Qualidade

Um dos princpios orientadores do Scrum, o de desenvolver em primeiro lugar a funcionalidade de maior


prioridade para o cliente. Recursos menos importantes so desenvolvidos em Sprints subsequentes ou
podem ser deixados de fora de acordo com as necessidades do cliente. Esta abordagem d ao Time Scrum
o tempo necessrio para se concentrar na qualidade de funcionalidade essencial. Um dos principais
benefcios do planejamento da qualidade, a reduo da dvida tcnica. A Dvida Tcnica (tambm referida
como dvida de design ou dvida de cdigo) refere-se ao trabalho que os times classificam com prioridade
inferior, omitente ou como no completado, j que eles trabalham para criar os principais entregveis
associados com o produto do projeto. A Dvida Tcnica acumula e deve ser paga no futuro.

Algumas causas de dvida tcnica podem incluir:


5
O conserto rpido e a construo de entregas que no cumprem os padres de qualidade,
segurana, objetivos de arquitetura de longo prazo, etc.
Os testes inadequados ou incompletos
A documentao incorreta ou incompleta
A falta de coordenao entre os diferentes membros do time, ou se diferentes Times Scrum
comearem a trabalhar de forma isolada, com menos foco na integrao final dos componentes
necessrios para a realizao de um projeto ou programa de sucesso
A falta de compartilhamento de conhecimento do negcio e de processos entre os stakeholders e
os times do projeto
O excesso de foco em objetivos do projeto de curto prazo, ao invs dos objetivos de longo prazo
para empresa. Este equvoco pode resultar em Entregveis em Funcionamento de baixa qualidade,
o que pode gerar a necessidade significativa de manuteno, e em custos para realizar uma
atualizao.

Em projetos Scrum, nenhuma dvida tcnica deve ser transferida para outro Sprint, porque os Critrios de
Aceitao e de Pronto devem existir, claramente definidos. A funcionalidade deve satisfazer esses critrios
para ser considerada Pronta. Assim que o Backlog Priorizado do Produto refinado e as Estrias de
Usurio so priorizadas, o time regularmente cria os Entregveis em Funcionamento, evitando o acmulo
significativo de dvida tcnica. O Scrum Guidance Body pode tambm incluir documentao e definio de
processos que ajudem a diminuir a dvida tcnica.

Para manter uma quantidade mnima de dvida tcnica, importante definir o produto necessrio de um
Sprint e do projeto, juntamente com os Critrios de Aceitao, com os mtodos de desenvolvimento a
serem seguidos, e com as principais responsabilidades dos membros do Time Scrum em relao
qualidade. A definio dos Critrios de Aceitao uma parte importante do planejamento de qualidade, e
permite o controle eficaz da qualidade a ser realizado durante o projeto.

A dvida tcnica um desafio muito grande, com algumas tcnicas de gerenciamento de projetos
tradicionais, onde o desenvolvimento, testes, documentao, etc, so feitos sequencialmente e, muitas
vezes vezes por pessoas diferentes, sem ter uma nica pessoa responsvel por qualquer Entregvel em

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 91


5 QUALIDADE

Funcionamento em particular. Como resultado, as dvidas tcnicas acumulam, gerando custos


significativamente mais elevados de manuteno, integrao e lanamento de produtos, durante a fase final
da release do projeto. Alm disso, o custo das mudanas muito elevado em tais circunstncias, j que
problemas podem aparecer em fases posteriores do projeto. O framework Scrum impede os problemas
relacionados com a dvida tcnica, garantindo que os entregveis Prontos com Critrios de Aceitao,
sejam definidos como parte do Backlog do Sprint, e que tarefas-chave (incluindo o desenvolvimento, teste e
documentao), sejam feitas como parte do mesmo Sprint e realizadas pelo mesmo Time Scrum.

5.5.1.1 Integrao Contnua e Ritmo Sustentvel

A manuteno de um ritmo sustentvel um dos princpios mais importantes do Scrum. O ritmo sustentvel se
traduz em aumento da satisfao dos colaboradores, de estabilidade e de preciso de estimativa, os quais, em
uma ltima anlise aumentam a satisfao do cliente. Para desenvolver um produto verdadeiramente de alta
qualidade e manter um ambiente de trabalho saudvel, importante a realizao regular de atividades de
integrao. Para fornecer o valor em intervalos frequentes, o time deve continuamente desenvolver, testar e
integrar as funcionalidades de cada Item do Backlog Priorizado do Produto, em cada Sprint, com o uso de
tcnicas como a integrao contnua e testes de produtos automatizados. Do ponto de vista do time, tambm
importante garantir que o esforo despendido no atual Sprint seja semelhante ao esforo gasto no Sprint
anterior, a fim de manter o mesmo ritmo durante todos os Sprints do projeto. Isso ajuda o time a evitar fases de
perodos intensos de trabalho, garantindo que sejam sempre capazes de levar a diante o nvel de esforo
necessrio para realizar o trabalho que precisa ser feito.

5.5.2 Controle de Qualidade e Garantia de Qualidade

O Controle de Qualidade refere-se execuo das atividades de qualidade planejadas pelo Time Scrum, no
processo de criao das entregas que so potencialmente utilizveis. Tambm inclui aprender a partir de cada
conjunto de atividades concludas, a fim de alcanar a melhoria contnua. Dentro de times multifuncionais,
importante ter as habilidades necessrias para realizar as atividades de controle de qualidade. Durante a
Reunio de Retrospectiva do Sprint, os membros do time discutem as lies aprendidas. Estas lies agem
como inputs para a melhoria contnua e contribuem para a melhoria do controle de qualidade em curso.

A qualidade necessria no apenas em produtos, mas tambm em processos. A garantia de qualidade


refere-se avaliao de processos e normas que regem o gerenciamento de qualidade em um projeto, para
garantir que eles continuam a ser relevantes. As atividades de garantia de qualidade so realizadas como parte
do trabalho. Na verdade, a garantia da qualidade um fator importante da definio de Pronto. A entrega no
considerada completa se a garantia de qualidade no for realizada adequadamente. Muitas vezes, a garantia
da qualidade demonstrada durante a Reunio de Reviso do Sprint.

Os Donos do Produto podem monitorar e avaliar as atividades de garantia de qualidade, para garantir que cada
time continua a concordar e cumprir com os padres de qualidade que foram estabelecidos respectivamente

92 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

para os projetos, programas e portflios. A garantia de qualidade End-to-end pode ser abordada durante os
testes finais do produto, da Release ou do Sprint. Pode ser feito uma comparao entre o nmero de
problemas encontrados versus o nmero de Estrias de Usurio concludas. Os componentes do produto que
possuem defeitos podem ser incorporados como Itens do Backlog Priorizado do Produto, os quais podero ser
trabalhados pelo time, ou por uma pessoa, em determinados momentos durante o Sprint, dependendo do
nmero de defeitos.

s vezes, o Scrum Guidance Body pode definir os processos e documentos que podem ser referidos pelos
Times Scrum ao realizarem os seus projetos, para garantir que as normas de qualidade sejam seguidas de
maneira uniforme por todos os projetos dentro da empresa.

5
5.5.3 O Ciclo PDCA Planejar-Fazer-Verificar-Agir (Plan-Do-Check-Act)

O Ciclo Plan-Do-Check-Act (Planejar-Executar-Verificar-Agir)tambm conhecido como o Ciclo Deming ou


Shewhartfoi desenvolvido pelo Dr. W. Edwards Deming, considerado o pai do controle de qualidade
moderno e Dr. Walter A. Shewhart. A seguir esto alguns dos pontos importantes da filosofia de Deming:

O gerenciamento de diretrizes define a qualidade. Quando a administrao capaz de fornecer um


ambiente propcio, e de motivar seus colaboradores para melhorar a qualidade de forma contnua,
cada colaborador pode contribuir para um produto de qualidade superior. A Teoria de Deming sobre
o Conhecimento Profundo" defende o que a administrao deve fazer, a fim de criar um ambiente
em que cada colaborador possa contribuir significativamente para a melhoria da qualidade.

Deming modificou o ciclo Plan-Do-Check-Act para Plan-Do-Study-Act (Panejar-Executar-Estudar-Agir),


porque ele considerou que o termo "Estudar" enfatiza a anlise, ao invs de simplesmente inspeo, como
sugere o termo "Verificar".

Tanto Scrum quanto o Ciclo Deming/ Shewhart/ PDCA so mtodos iterativos que se concentram na
melhoria contnua.

A figura 5-3 ilustra as etapas do ciclo PDCA e sua correlao com vrios processos do Scrum.

Criar o Backlog Priorizadodo Criar Entregas


Produto Conduzir a Reunio Diria
Criar as Estrias de Usurio
Planejar Executar

Verificar/
Agir
Studar
Envio de Entregveis Demonstrar e Validar o Sprint
Retrospectiva do Projeto Retrospectiva do Sprint

Figura 5-3: O Ciclo PDCA em Scrum

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 93


5 QUALIDADE

5.6 Resumo das Responsabilidades

Papis Responsabilidades
Fornecer a definio de Pronto
Scrum Guidance Fornecer o framework e a orientao para o desenvolvimento dos Critrios de Aceitao
Body Definir o conjunto de ferramentas que podem ser utilizadas pelo Time Scrum para
desenvolver e verificar o produto
Dono do Produto do Definir os Critrios Mnimos de Aceitao para todo o portflio
Portflio Revisar as entregas do portflio
Scrum Master do Garantir que um ritmo sustentvel seja mantido, em que o foco esteja na qualidade dos
Portflio recursos e no estritamente na velocidade
Dono do Produto do Definir os Critrios Mnimos de Aceitao para todo o programa
Programa Revisar as entregas do programa
Scrum Master do Garantir que um ritmo sustentvel seja mantido, em que o foco esteja na qualidade dos
Programa recursos e no estritamente na velocidade
Stakeholder(s) Revisar e aceitar os Entregveis e o produto final
Declarar os requisitos de negcio para o produto e definir claramente os requisitos do
Backlog Priorizado do Produto
Avaliar a viabilidade e garante que as entregas atendem aos requisitos de qualidade
Dono do Produto Definir os Critrios Mnimos de Aceitao para todo o projeto, incluindo os Critrios de
Aceitao do respectivo programa
Facilitar a criao de Critrios de Aceitao para as Estrias de Usurio
Revisar e validar os Entregveis durante o processo de Demonstrar e Validar o Sprint
Facilitar uma mentalidade de time em primeiro lugar quando se trata de qualidade
Eliminar os obstculos ambientais que podem afetar a qualidade das entregas e dos
processos
Scrum Master Garantir que um ritmo sustentvel seja mantido, em que o foco esteja na qualidade dos
recursos e no estritamente na velocidade
Garantir que os processos do Scrum sejam seguidos corretamente por todos os
membros do time, incluindo o Dono do Produto
Desenvolver e manter todas as entregas durante os Sprints, at que sejam entregues
aos usurios finais
Praticar e incentivar a boa comunicao para que os requisitos sejam esclarecidos e
totalmente compreendidos
Time Scrum
Compartilhar o conhecimento para garantir que os membros do time se familiarizam com
todo o conjunto de recursos e, com isso, se beneficiam da experincia de outras
pessoas
Fazer rapidamente mudanas apropriadas aos Entregveis

Tabela 5-1: Resumo das Responsabilidades Relevantes de Qualidade

94 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


5 QUALIDADE

5.7 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


Embora existam semelhanas, entre o Scrum e os mtodos tradicionais de gerenciamento de projeto, no
que se diz respeito definio de "qualidade" (como, a capacidade do produto em satisfazer os Critrios de
Aceitao acordados, e em alcanar o valor de negcio esperado pelo cliente), tambm existem diferenas
em termos de como as abordagens direcionam a implementao e o cumprimento dos nveis exigidos de
qualidade.

Nos mtodos tradicionais de gerenciamento de projetos, os usurios esclarecem suas expectativas; o


gerente do projeto define as expectativas em termos mensurveis e recebe o consentimento dos usurios.
Depois de um planejamento detalhado, o time do projeto desenvolve o produto durante um perodo de
tempo acordado. Se algum dos critrios acordados precisarem ser modificados, as mudanas s podem 5
ocorrer atravs de um sistema de gerenciamento de mudana formal, onde o impacto das mudanas
estimado e o Gerente do Projeto recebe aprovao de todos os stakeholders.

No entanto, em Scrum, o Dono do Produto colabora com o Time Scrum e define os Critrios de Aceitao
para as Estrias de Usurio relacionadas com o produto a ser entregue. O Time Scrum em seguida,
desenvolve o produto de uma srie de iteraes curtas chamadas Sprints. O Dono do Produto pode
modificar os requisitos para manter o ritmo com as necessidades do usurio e essas mudanas podem ser
abordadas pelo Time Scrum, seja encerrando o atual Sprint ou incluindo os requisitos ajustados no prximo
Sprint j que possuem curta durao (de uma a seis semanas).

Uma das principais vantagens do Scrum a nfase na criao de entregveis potencialmente utilizveis no
final de cada ciclo do Sprint, ao invs de ser realizada apenas no final de todo o projeto. Sendo assim, o
Dono do Produto e os clientes constantemente inspecionam, aprovam e aceitam as entregas aps cada
Sprint. Alm disso, mesmo que um projeto Scrum seja encerrado, sempre existe algum valor criado antes
de sua resciso, atravs das entregas criadas em Sprints individuais.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 95


5 QUALIDADE

96 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

6. MUDANA

6.1 Introduo
Todo projeto, independentemente do mtodo ou do modelo utilizado, est sujeito a mudanas. imperativo
que os membros do time do projeto compreendam que os processos de desenvolvimento Scrum so
projetados para aceitar estas mudanas. As organizaes devem tentar maximizar os benefcios
decorrentes de mudanas e minimizar quaisquer impactos negativos por meio de processos diligentes de
gerenciamento de mudana, de acordo com os princpios do Scrum.

Tal como definido em Um Guia para o Conhecimento em Scrum (Guia SBOK), a Mudana aplicvel em:
6
Portflio, programas e/ou projetos em qualquer indstria
Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Este captulo est dividido nas seguintes sees:

6.2 Guia dos PapisEsta seo fornece orientao sobre quais sees so relevantes para cada um dos
papis centrais do Scrum: Dono do Produto, Scrum Master, e Time Scrum.

6.3 Viso geralEsta seo define o conceito de mudana, especialmente no contexto dos processos do
Scrum. Tambm aborda como as Solicitaes de Mudana so tratadas em processos do Scrum.

6.4 Mudana em ScrumEsta seo detalha a importncia da gerncia eficaz de mudanas em um


projeto Scrum. Tambm aborda como flexibilidade e estabilidade podem ser alcanadas atravs da
superviso adequada das Solicitaes de Mudana que surgem ao longo de um projeto.

6.5 Integrao de MudanasEsta seo detalha como Solicitaes de Mudana so avaliadas e


aprovadas (ou rejeitadas) quando o framework Scrum aplicado.

6.6 Mudana em Portflios e ProgramasEsta seo descreve o impacto das mudanas em programas e portflios.

6.7 Resumo das Responsabilidades Esta seo define as responsabilidades dos membros do time do
projeto no gerenciamento de mudana.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 97


6 MUDANA

6.8 O Scrum x O Modelo Tradicional de Gerenciamento de ProjetosEsta seo discute os benefcios


do gerenciamento de mudana atravs de mtodos Scrum, em relao aos mtodos utilizados nos modelos
tradicionais de gerenciamento de projetos.

6.2 Guia dos Papis


1. Dono do ProdutoA responsabilidade de iniciar a mudana em um projeto principalmente do
Dono do Produto, portanto, esse captulo inteiro aplicvel a este papel.

2. Scrum MasterO Scrum Master tambm deve estar familiarizado com este captulo inteiro com
foco principal nas sees 6.3, 6.4, 6.5 e 6.7.

3. Time ScrumO Time Scrum deve se concentrar principalmente nas sees 6.3, 6.4.2, 6.5 e 6.7.

6.3 Viso geral


A mudana inevitvel em todos os projetos. No mundo hipercompetitivo de hoje, onde a tecnologia,
condies de mercado e padres de negcios sofrem alteraes continuamente, a mudana a nica
constante.

Um princpio fundamental do Scrum reconhecer que 1) os stakeholders (por exemplo, clientes, usurios e
patrocinadores) mudam de ideia muitas vezes durante o projeto, sobre o que eles querem e precisam
(muitas vezes similar a uma batedeira de requisitos) e 2) muito difcil, se no impossvel, para os
stakeholders definirem todos os requisitos durante o incio do projeto.

Os projetos de desenvolvimento do Scrum acolhem a mudana, utilizando pequenos ciclos de


desenvolvimento que incorporam o feedback dos clientes nas entregas do projeto, depois de cada Sprint.
Isso permite que o cliente veja os incrementos dos produtos, assim que prontos, e mudem os requisitos
mais cedo no ciclo de desenvolvimento, interagindo regularmente com os membros do Time Scrum. Alm
disso, os times de gerenciamento de programa ou de portflio podem responder s Solicitaes de
Mudana pertencentes aos projetos Scrum aplicveis ao seu nvel.

O Scrum incorpora um princpio fundamental do Manifesto gil (Fowler e Highsmith, 2001): "Responder s
mudanas ao invs de seguir um plano." O Scrum praticado com base em abraar a mudana e
transform-la em uma vantagem competitiva. Portanto, mais importante ser flexvel do que seguir um
plano rigoroso e pr-definido. Isto significa que essencial a abordagem de gerenciamento de projetos de
forma adaptativa que permite a mudana ao longo do desenvolvimento rpido do produto, ou ciclos de
desenvolvimento de servios.

98 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

Ser adaptvel mudana uma das principais vantagens do framework Scrum. Embora o Scrum funcione
bem para todos os projetos e em todas as indstrias, pode ser muito eficaz quando o produto ou outros
requisitos do projeto no so totalmente compreendidos ou, no podem ser bem definidos
antecipadamente, quando o mercado do produto voltil, e/ou quando o foco tornar o time
suficientemente flexvel para incorporar requisitos de mudana. O Scrum especialmente til para projetos
complexos, com muitas incertezas. O planejamento e a previso de longo prazo so tipicamente ineficazes
para tais projetos e envolvem grandes quantidades de risco. O Scrum orienta o time atravs da
transparncia, inspeo e adaptao aos resultados de negcios mais valiosos.

6.3.1 As Solicitaes de Mudanas Aprovadas e No-Aprovadas

Os pedidos por mudanas so geralmente apresentados na forma de Solicitaes de Mudanas. As


6
Solicitaes de Mudanas permanecem em um estado no aprovado at que sejam formalmente
aprovadas. O Scrum Guidance Body geralmente define um processo de aprovao e gerenciamento de
mudanas para toda a organizao. Na ausncia de um processo formal, recomenda-se que pequenas
mudanas, que no tm impacto significativo sobre o projeto sejam aprovadas diretamente pelo Dono do
Produto. A tolerncia para essas pequenas mudanas pode ser definida em um nvel organizacional ou pelo
patrocinador de um projeto em particular. Na maioria dos projetos, 90% das solicitaes de mudanas
podem ser classificadas como pequenas mudanas, que devem ser aprovadas pelo Dono do Produto.
Sendo assim, o Dono do Produto desempenha um papel muito importante no gerenciamento de mudanas
em um projeto Scrum.

As mudanas que esto alm do nvel de tolerncia do Dono do Produto podem precisar da aprovao dos
stakeholders que trabalham com o Dono do Produto.

s vezes, a autorizao da direo pode ser necessria (o Patrocinador Executivo, Dono do Produto do
Portflio, Dono do Produto do Programa, ou o Dono do Produto Chefe), se a modificao solicitada tiver um
impacto substancial sobre o projeto ou organizao.

As Solicitaes de Mudana para o projeto so discutidas e aprovadas durante os processos de


Desenvolver os pico(s), de Criar o Backlog Priorizado do Produto e de Refinamento do Backlog Priorizado
do Produto. As Solicitaes de Mudana Aprovadas so ento priorizadas juntamente com outros requisitos
do produto e suas respectivas Estrias de Usurio, e depois so incorporadas no Backlog Priorizado do
Produto.

A figura 6-1 resume o processo de aprovao de mudana e a figura 6-2 explica como o Backlog Priorizado
do Produto atualizado com as mudanas aprovadas.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 99


6 MUDANA

Figura 6-1: Exemplo do Processo de Aprovao de Mudana

Figura 6-2: Atualizando o Backlog Priorizado do Produto com as Mudanas Aprovadas

100 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

6.4 Mudana em Scrum

6.4.1 O Equilbrio entre a Flexibilidade e a Estabilidade

O Scrum ajuda as organizaes a se tornarem mais flexveis e abertas a mudanas. No entanto,


importante compreender que embora o framework Scrum realce a flexibilidade, tambm importante
manter a estabilidade durante todo o processo de mudana. Da mesma forma que a rigidez extrema
ineficaz, a flexibilidade extrema tambm improdutiva. A chave encontrar o equilbrio certo entre a
flexibilidade e a estabilidade, porque a estabilidade necessria, para a concluso do trabalho. Portanto, o
Scrum utiliza a entrega iterativa e suas outras caractersticas e princpios para alcanar esse equilbrio. O
Scrum mantm a flexibilidade onde as Solicitaes de Mudana podem ser criadas e aprovadas em
qualquer momento durante o projeto, no entanto, so priorizadas quando o Backlog Priorizado do Produto
criado ou atualizado. Ao mesmo tempo, o Scrum garante que a estabilidade seja mantida, gerenciando o 6
Backlog fixo do Sprint e no permitindo a interferncia do Time Scrum durante um Sprint.

Em Scrum, todos os requisitos relacionados a um Sprint em curso, so congelados durante o mesmo.


Nenhuma mudana introduzida antes do final do Sprint, a menos que a mudana seja considerada
significativa o suficiente para parar o Sprint. No caso de uma mudana urgente, o Sprint encerrado e o
time se rene para planejar um novo Sprint. Esta forma como o Scrum aceita mudanas, sem criar o
problema de alterao de datas de lanamento.

6.4.2 Conquistando a Flexibilidade

O Scrum facilita a flexibilidade atravs da transparncia, inspeo e adaptao para finalmente alcanar os
resultados de negcio mais valiosos. O Scrum fornece um mecanismo adaptativo para o gerenciamento de
projetos, em que uma mudana nos requisitos possa ser acomodada sem afetar significativamente o
progresso do projeto. necessrio adaptar-se s realidades emergentes do negcio como parte do ciclo de
desenvolvimento. A flexibilidade em Scrum adquirida atravs de cinco caractersticas essenciais (ver
Figura 6-3): desenvolvimento iterativo do produto, Time-boxing, times multifuncionais, priorizao baseada
no valor para o cliente, e integrao contnua.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 101


6 MUDANA

Figura 6-3: As Caractersticas do Scrum para Adquirir Flexibilidade

6.4.2.1 A Flexibilidade atravs do Desenvolvimento Iterativo de Produto

O Scrum segue uma abordagem iterativa e incremental para o desenvolvimento de produtos e servios,
tornando possvel a incorporao de alteraes em qualquer etapa do processo de desenvolvimento. O
produto, ao ser desenvolvido, pode receber Solicitao de Mudana para o projeto oriundas de vrias
fontes:

1. Stakeholders

Stakeholders do projeto (patrocinadores em particular, clientes, e usurios) podem apresentar


Solicitaes de Mudana a qualquer momento durante o projeto. As Solicitaes de Mudana
podem ser devido a alteraes nas condies de mercado, direo organizacional, questes legais
ou regulamentares, ou vrios outros motivos. Alm disso, os stakeholders podem enviar
Solicitaes de Mudana enquanto esto revisando as entregas durante os processos de
Demonstrar e Validar o Sprint, Retrospectiva do Sprint, ou Retrospectiva do Projeto. Todas as
Solicitaes de Mudana, uma vez que sejam aprovadas, so adicionadas ao Backlog Priorizado
do Produto do Projeto (tambm referido, como Backlog Priorizado do Produto ou Backlog do
Produto). A figura 6-4 demonstra algumas das razes pelas quais os stakeholders iniciam o
processo de Solicitao de Mudana.

102 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

Figura 6-4: O Motivo que leva os Stakeholders a Solicitar Mudanas

2. Time Central do Scrum

O Time Central do Scrum (Dono do Produto, Scrum Master e Time Scrum) est envolvido na
criao das entregas do produto. A interao contnua entre os membros do Time Central do
Scrum em um Time Scrum, tal qual outros Times Scrum envolvidos no projeto, acrescido dos
stakeholders, internos e externos, podem motivar o Time Central do Scrum a sugerir mudanas ou
melhorias para o produto, servio ou para alguma outra parte do projeto. Normalmente essas
mudanas, como outras quaisquer, so capturadas nas Solicitaes de Mudana, e o Dono do
Produto toma a deciso final sobre quais mudanas, sugeridas pelo Time Scrum e Scrum Master,
devem ser consideradas como Solicitaes de Mudana formais.

s vezes podem haver desafios na criao de alguns entregveis, podendo resultar em


Solicitaes de Mudana. Por exemplo, o time pode optar por um novo recurso a ser adicionado ou
modificado, para melhorar o desempenho do produto. Na maioria dos projetos do Scrum, as

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 103


6 MUDANA

recomendaes de mudanas vindas do Time Central do Scrum, ocorrem quando os Times Scrum
esto trabalhando para Criar os Entregveis, ou quando participam da Reunio Diria ou Reunies
de Retrospectiva do Sprint. A figura 6-5 demonstra algumas das razes pelas quais o Time Central
do Scrum d incio a Solicitaes de Mudana.

Figura 6-5: O Motivo que leva o Time Central do Scrum a Solicitar Mudanas

3. Alta Administrao

A Alta Administrao, incluindo a gerncia de portflio e de programa, pode recomendar mudanas


que afetam o projeto. Isso pode ser por causa de mudanas na direo estratgica da empresa,
cenrio competitivo, problemas ligados ao seu financiamento, e assim por diante. Note que tais
mudanas so adicionadas ao Backlog Priorizado do Produto e precisam passar pelo processo
comum de gerenciamento de mudana. Se alguma dessas mudanas for urgente, talvez o Sprint
impactado precise ser encerrado (ver seo 6.6 para mais detalhes).

104 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

4. Scrum Guidance Body

O Scrum Guidance Body pode submeter Solicitaes de Mudana que afetam todos os projetos,
devido a qualquer um dos seguintes exemplos:

Mudana na regulamentao do governo, como por exemplo, privacidade, padres de


segurana, ou nova legislao
Diretrizes corporativas para a qualidade, segurana ou outras iniciativas organizacionais
que precisem ser implementadas em toda a empresa
Benchmarks ou melhores prticas para atender a um determinado padro
As lies aprendidas em projetos anteriores, que possam ser implementadas por outros
Times Scrum

A marca registrada do Scrum que ele tolerante e adaptativo mudana. O Scrum no promove a
criao de planos fixos e determinados com antecedncia, porque opera na premissa de que o 6
desenvolvimento do projeto extremamente propenso a correr riscos e promover mudanas. O resultado
um grau elevado de flexibilidade e de tolerncia a mudana. O projeto planejado, executado e gerido de
forma incremental, por isso, normalmente fcil de se incorporar mudanas, do comeo ao fim.

6.4.2.2 A Flexibilidade atravs de Time-boxing

O Time-boxing refere-se definio de perodos curtos de tempo em que o trabalho deve ser realizado. Se
no final do Time-box o trabalho permanecer incompleto, o mesmo transferido para um Time-box posterior.
Exemplos de Time-boxing incluem a estipulao do limite de 15 minutos para as Reunies Dirias e a
durao de 1 a 6 semanas para o Sprint. Os Time-boxes fornecem a estrutura necessria para os projetos
Scrum, que tm um elemento de incerteza, so dinmicos por natureza, e so propensos a mudanas
frequentes. Os Time-boxes ajudam a medir o progresso do projeto e permitir que o time possa identificar
facilmente a necessidade em modificar um processo ou abordagem.

Os Sprints Time-boxed contribuem muito no cumprimento de prazos e no alcance de altos nveis de


produtividade. Os Sprints promovem ordem e consistncia em um ambiente de trabalho voltil. Fornecem
uma plataforma para avaliar os resultados e obter feedback em um curto espao de tempo. Os Sprints
tambm permitem uma avaliao frequente do progresso e dos mtodos utilizados para gerenciar o projeto,
incluindo o gerenciamento de mudana efetiva. Os erros ou problemas podem ser identificados
precocemente podendo ser rapidamente corrigidos.

Usando o Time-boxing em Sprints, o time revisa frequentemente o processo de estimar o trabalho a ser
realizado, de modo que a projeo de tempo e de esforos necessrios tornam-se mais precisos com cada
Sprint subsequente, no decorrer do projeto. Estes ciclos iterativos tambm motivam os membros do time a
atingirem os objetivos projetados e as metas incrementais para alcanar o objetivo maior.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 105


6 MUDANA

6.4.2.3 A Flexibilidade atravs de Times Multifuncionais e Auto-organizados

As estruturas multifuncionais e auto-organizadas do Time Scrum permitem que os membros do time


estejam extremamente focados nos resultados desejados do Sprint. O time tem um conjunto definido de
objetivos durante cada Sprint e a flexibilidade em considerar a mudana nos objetivos, antes de iniciar o
prximo Sprint.

O uso de times multifuncionais tambm garante a existncia, dentro do prprio time, de todas as
habilidades e conhecimentos necessrios para a realizao do trabalho do projeto. Isto fornece um modelo
de trabalho eficiente que resultar na criao de entregas que sero potencialmente utilizveis e prontas
para serem demonstradas para o Dono do Produto e/ou outros stakeholders.

A auto-organizao garante que os membros do Time Scrum determinem por conta prpria, como fazer o
trabalho do projeto sem a necessidade de existir um gerente snior supervisionando suas tarefas.

Tendo times multifuncionais e auto-organizados permite ao grupo a adaptao e o gerenciamento eficaz do


trabalho em andamento e de quaisquer mudanas ou problemas menores, sem ter que obter o apoio ou
conhecimento de membros fora do time, e no processo, criar entregas que esto prontas para serem
enviadas, se necessrio.

6.4.2.4 A Flexibilidade atravs da Priorizao Baseada em Valor para o Cliente

A priorizao de requisitos e de trabalho em um projeto Scrum sempre determinada com base no valor
fornecido ao cliente. Primeiramente, no incio de um projeto, os requisitos iniciais so priorizados com base
no valor que cada requisito ir fornecer, sendo documentados no Backlog Priorizado do Produto. Ento,
quando uma solicitao feita para um novo requisito ou para a mudana de um requisito j existente, a
mesma, avaliada durante o processo de Refinamento do Backlog Priorizado do Produto. Se a mudana
fornecer um valor maior do que outros requisitos existentes, esta ser adicionada e priorizada
adequadamente no Backlog do Produto Priorizado e Atualizado, j que o mesmo permite a incorporao de
modificaes e a adio de novos requisitos, quando necessrio.

importante notar que os novos requisitos e mudanas adicionados ao Backlog Priorizado do Produto
podem diminuir a prioridade de outras Estrias de Usurios existentes no Backlog. Assim, essas Estrias
de Usurio priorizadas inferiormente podem ser implementadas mais tarde, dependendo de sua nova
priorizao. O envolvimento dos clientes na priorizao de requisitos e suas Estrias de Usurio
correspondentes no Backlog Priorizado do Produto, garante que os requisitos que so considerados de
"alto valor" pelo cliente, sejam concludos rapidamente e consequentemente que o projeto comece a
entregar mais cedo um valor significativo.

106 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

6.4.2.5 A Flexibilidade atravs da Integrao Contnua

Usando tcnicas de integrao contnua, sempre que possvel, os membros do Time Scrum podem
incorporar funcionalidades novas e modificadas nas entregas. Isso reduz o risco de vrios membros do time
fazerem modificaes em componentes redundantes (por exemplo, um cdigo obsoleto em produtos de
software, designs antigos para fabricao de peas). Isso garante que o trabalho est sendo realizado em
apenas recursos ou verses atualizadas, evitando problemas de compatibilidade.

6.5 Integrao de Mudanas


Dependendo da indstria e do tipo de projeto, a prioridade de recursos e requisitos para um projeto podem
permanecer fixos por perodos de tempo significativos, ou eles podem mudar frequentemente. Se os
requisitos do projeto so geralmente estveis, so feitas apenas pequenas mudanas no Backlog 6
Priorizado do Produto ao longo do desenvolvimento, e os Times Scrum podem trabalhar sequencialmente,
completando os requisitos que proporcionem o mximo valor ao cliente conforme a priorizao feita no
Backlog Priorizado do Produto. Em ambientes estveis, a durao do Sprint geralmente mais longa (de 4
a 6 semanas).

Se os requisitos de projeto mudam ao longo do projeto, por exemplo, devido a mudana dos requisitos de
negcio, o mesmo mtodo continua a ser eficaz. Antes de iniciar um Sprint (durante os processos de Criar o
Backlog Priorizado do Produto ou de Refinamento do Backlog Priorizado do Produto), os requisitos
prioritrios no Backlog Priorizado do Produto normalmente so selecionados para serem concludos
naquele Sprint. Pelo fato de que as mudanas j foram consideradas no Backlog Priorizado do Produto, o
time s precisa determinar quantas tarefas podem ser realizadas no Sprint, levando em conta o tempo e os
recursos fornecidos. O gerenciamento de mudana executado nos processos em desenvolvimento de
priorizao e adio de tarefas no Backlog Priorizado do Produto.

6.5.1 As Mudanas em um Sprint

Se houver uma Solicitao de Mudana que pode ter impacto significativo sobre o Sprint em andamento, o
Dono do Produto, aps consultar os stakeholders, decide se a mudana pode esperar at o prximo Sprint
ou se representa uma situao de emergncia, em que pode-se exigir o encerramento do Sprint atual,
dando incio a um novo.

O Framework Scrum especifica claramente que o escopo de um Sprint no pode ser alterado uma vez que
seu processo seja iniciado. O Sprint dever ser encerrado se a mudana necessria inutilizar os resultados
do Sprint atual. Caso contrrio, a mudana ento ser incorporada em um Sprint posterior (de acordo com a
figura 6-6).

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 107


6 MUDANA

Figura 6-6: Integrando Mudanas em Scrum

Existe apenas uma exceo a essa regra de no alterar o escopo de um Sprint uma vez que iniciado. Se o
Time Scrum determinar que o esforo durante o Sprint foi superestimado e que na verdade, tem capacidade
extra para implementar Estrias de Usurio adicionais, o time pode perguntar para o Dono do Produto quais
Estrias de Usurio devem ser includas no Sprint atual.

Ao bloquear o escopo de cada Sprint, o time capaz de otimizar e gerenciar eficientemente o seu trabalho
e empenho. Um benefcio adicional que o time no precisa se preocupar com o gerenciamento de

108 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

mudanas, uma vez que os trabalhos em um Sprint sejam iniciados. Esta uma grande vantagem do
framework Scrum, em comparao com o modelo tradicional de gerenciamento de projeto.

No modelo tradicional de gerenciamento de projeto, as mudanas podem ser solicitadas e aprovadas a


qualquer momento durante o ciclo de vida do projeto. Isso muitas vezes gera confuso para os membros do
time, diminuindo sua motivao devido a descontinuidade, e resultando em uma falta de foco juntamente
com a sensao de que "nada concludo." Por outro lado, em projetos Scrum, as mudanas no so
permitidas uma vez que o Sprint iniciado. Isso garante que em cada Sprint o time completa entregveis, e
tarefas so Prontas. Alm disso, a empresa reconhece os benefcios tangveis de Entregveis
potencialmente utilizveis no final de cada Sprint.

E ainda, j que o Dono do Produto e os Stakeholders esto conscientes de que as mudanas no so


permitidas uma vez que o Sprint iniciado, e que a durao de um Sprint de 1 a 6 semanas, os requisitos
so definidos e priorizados durante os processos adequados de Criar os pico(s), Criar o Backlog
Priorizado do Produto, e Refinamento do Backlog Priorizado do Produto. 6

6.5.1.1 O Impacto da Mudana Esperada na Durao do Sprint

Como as mudanas no so permitidas durante o Sprint, o impacto e a frequncia das mudanas


esperadas podem ter um impacto no processo de deciso sobre a durao do Sprint, sendo este
determinado durante o processo de Conduzir o Planejamento da Release.

Se os requisitos do projeto so geralmente estveis e grandes mudanas no so esperadas em um futuro


prximo, a durao de um Sprint pode ser maior (de 4 a 6 semanas). Isso proporciona estabilidade para os
membros do Time Scrum, tendo mais tempo para trabalhar nos requisitos do Backlog Priorizado do Produto
sem ter que passar pelos processos de Criar as Estrias de Usurio; Aprovar, Estimar e Comprometer as
Estrias de Usurio; Criar as Tarefas; Estimar as Tarefas; entre outros processos relacionados, que so
realizados para cada Sprint.

No entanto, se os requisitos do projeto no esto bem definidos ou se mudanas significativas so


esperadas num futuro imediato, a Durao do Sprint pode ser relativamente curta (de 1 a 3 semanas). Isso
proporciona estabilidade para os membros do Time Scrum, para trabalhar em Sprints mais curtos e
entregar resultados, o que pode ser avaliado pelo Dono do Produto e pelos Stakeholders no final do Sprint.
Isso tambm proporciona flexibilidade suficiente para esclarecer requisitos e para modificar o Backlog
Priorizado do Produto no final de cada Sprint.

Para obter o mximo de benefcios a partir de um projeto Scrum, sempre recomendvel manter o Sprint
Time-boxed em 4 semanas, a no ser que hajam projetos com requisitos muito estveis, onde os Sprints
podem ser estendidos para at 6 semanas.

A figura 6-7 retrata o impacto da mudana esperada na Durao do Sprint.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 109


6 MUDANA

Figura 6-7: Impacto da Mudana Esperada na Durao do Sprint

No entanto, importante notar que a mudana esperada no o nico fator usado para determinar a
Durao do Sprint. Outros fatores que tambm precisam ser considerados incluem:

O tempo real para concluir o trabalho (se o projeto ou ambiente corporativo precisa de um tempo
especfico para realizar suas tarefas, estes podem determinar a Durao do Sprint)
Data prevista para o lanamento (a Durao do Sprint deve levar em considerao de forma geral,
as datas de lanamento para o produto ou servio)
Qualquer outro fator, conforme determinado pelo Dono do Produto ou Scrum Master, que precise
ser considerado ao determinar a Durao do Sprint

importante notar que a mudana da Durao do Sprint no deve ser decidida rapidamente, ou
periodicamente (por exemplo, no aconselhvel a variao de 3 semanas neste sprint, 2 semanas no
seguinte, 4 semanas no prximo Sprint, etc), a Durao do Sprint deve, preferencialmente, ser consistente.
Um dos maiores impactos da mudana na Durao do Sprint, que a mesma provoca um reset no projeto,
de forma geral. As velocidades anteriores podem se tornar inteis para a previso e planejamento dos
Sprints futuros. Sem uma velocidade exata (o que uma medida fundamental em qualquer projeto Scrum),
o Time Scrum no pode medir a eficcia ou escolher adequadamente o nmero de Estrias de Usurio que
faro parte do planejamento para o prximo sprint. Ento, uma vez que a Durao do Sprint decidida,

110 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

deve preferencialmente ser mantida constante ao longo da durao do projeto ou atravs de vrios ciclos
de Sprint.

6.5.1.2 Gerenciando as Mudanas atravs do Refinameto do Backlog Priorizado do Produto

Um Backlog Priorizado do Produto tpico, conter todas as Estrias de Usurio, suas estimativas de tempo
(incluindo quaisquer estimativas revisadas), e o status dos requisitos de maior prioridade. Quaisquer
Estrias de Usurios, novas ou revistas, resultantes de mudanas nos requisitos de negcio, solicitaes
dos clientes, condies do mercado externo e/ou lies aprendidas com os Sprints anteriores so tambm
incorporadas.

O refinamento do Backlog Priorizado do Produto uma das principais responsabilidades do Dono do


Produto, para garantir que os requisitos priorizados no Backlog Priorizado do Produto, a serem includos 6
nos prximos dois ou trs Sprints, sejam refinados em Estrias de Usurio adequadas. Recomenda-se que
o Dono do Produto gaste uma quantidade significativa de tempo em cada Sprint para o Backlog Priorizado
do Produto. O Dono do Produto responsvel por adicionar e rever itens do Backlog Priorizado do Produto,
em resposta a quaisquer mudanas, e responsvel pelo fornecimento de Estrias de Usurio mais
detalhadas que sero utilizadas para o prximo Sprint.

O refinamento ajuda a garantir que os requisitos e suas Estrias de Usurio sejam refinados antes da
Reunio de Planejamento do Sprint, para que o time tenha um conjunto de Estrias bem analisado e
claramente definido que pode ser facilmente dividido em tarefas e, posteriormente, estimados. Com base
nas lies aprendidas no Sprint atual, podem haver mudanas nos requisitos ou redefinio de prioridades,
que podem ser facilmente incorporadas em Sprints seguintes. O refinamento d suporte e aumenta a
flexibilidade do modelo Scrum atravs da incorporao de insights tcnicos e de negcios recentes, em
Sprints futuros.

Uma Reunio de Reviso do Backlog do Produto (tambm referida como uma Sesso de Refinamento do
Backlog Priorizado do Produto) uma reunio formal durante o processo de Refinamento do Backlog
Priorizado do Produto, que ajuda o Time Scrum a revisar e obter consenso sobre o Backlog Priorizado do
Produto. No entanto, diferente da Reunio de Reviso Backlog Priorizado do Produto, o Refinamento do
Backlog Priorizado do Produto deve acontecer ao longo do projeto e pode incluir situaes em que o Dono
do Produto escreve novas Estrias de Usurio ou reprioriza as Estrias de Usurio no Backlog Priorizado
do Produto existente, os membros do Time Scrum ou Stakeholders do suas sugestes sobre novas
Estrias de Usurio para o Dono do Produto, e assim por diante.

importante notar que qualquer item do Backlog Priorizado do Produto est sempre aberto para re-
estimativa, at que o Backlog do Sprint seja finalizado no processo de Criar o Backlog do Sprint . Depois
disso, as mudanas podem continuar a serem feitas imediatamente, at antes da Reunio de Planejamento
do Sprint, se necessrio.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 111


6 MUDANA

6.5.1.2.1 Reunio eficaz de Reviso do Backlog do Produto (ou Sesso de Refinamento do


Backlog Priorizado do Produto)

O Dono do Produto assume a liderana em uma Reunio de Reviso do Backlog do Produto que
realizada durante o processo de Refinamento do Backlog Priorizado do Produto. importante que o Dono
do Produto defina os objetivos e, idealmente, desenvolva uma programao antes da Reunio de Reviso
do Backlog do Produto comear. Sem isso, a sesso ser desestruturada e poder revelar-se improdutiva.
Tambm importante limitar o nmero de stakeholders que participaro da reunio. Ter muitos
participantes tende a diminuir a eficincia geral da reunio. O Dono do Produto deve convidar para a
sesso de refinamento, apenas os stakeholders cujo feedback necessrio. Todos os membros do Time
Scrum devem ser includos porque o seu feedback importante para o trabalho que est sendo realizado e
para quaisquer problemas encontrados. Se a sesso de refinamento resultar em qualquer re-priorizao ou
mudana no Backlog Priorizado do Produto, importante que o time esteja de acordo com essas
mudanas.

Uma sesso de refinamento eficaz deve resultar em Itens do Backlog Priorizado do Produto bem definidos,
para que o Time Scrum compreenda claramente quais so os requisitos do cliente. Isso tambm ajuda o
time a se familiarizar com todas as Estrias de Usurio, no caso de uma ou mais destas precisarem ser
includas, de ltima hora, em um Sprint . Os Critrios de Aceitao e os Critrios de Pronto tambm podem
ser discutidos durante as sesses de refinamento.

O Scrum no define um Time-box para os exerccios de refinamento. O refinamento do Backlog Priorizado


do Produto uma atividade contnua para o Dono do Produto.

6.5.1.3 Gerenciando Mudanas Durante o Processo de Demonstrar e Validar o Sprint

Embora o Dono do Produto tenha a palavra final sobre os Itens do Backlog Priorizado do Produto, e se
aceitar ou rejeitar quaisquer Estrias de Usurio (correspondente a Solicitaes de Mudana Aprovadas)
apresentadas durante o processo de Demonstrar e Validar o Sprint, do Scrum Master a responsabilidade
de garantir que os requisitos e os Critrios de Aceitao no sejam alterados, durante a Reunio de
Reviso do Sprint, para as Estrias de Usurio concludas no Sprint atual. Isso evita a rejeio das Estrias
de Usurio concludas com base no fato de que no atendem aos requisitos recentemente modificados. Se
algum requisito precisar ser modificado, os Itens do Backlog Priorizado do Produto correspondentes
precisam ser revistos para acomodar os novos requisitos em um Sprint futuro.

112 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

6.6 Mudana em Portflios e Programas


Qualquer modificao que ocorra nos programas ou portflios pode ter um efeito cascata em todos os
projetos e Sprints dependentes. Portanto, aconselhvel a minimizao de modificaes, para estes nveis
mais elevados. Se a mudana necessria e todos os stakeholders estiverem de acordo, deve-se manter
em mente os seguintes pontos.

6.6.1 Em Portflio

1. No recomendado fazer mudanas entre o perodo de duas Reunies do Backlog do Portflio.


2. Se a modificao for mnima, o Dono do Produto do Portflio deve garantir a aprovao dos
stakeholders (patrocinador, cliente e usurio final) e em seguida, adicionar os requisitos para o
6
Backlog do Portflio. Os Donos do Produto do programa e do projeto iro considerar estes
requisitos para incluso em Sprints futuros.
3. Se a mudana grande, os esforos do portflio, juntamente com os programas, projetos e Sprints
associados, precisam parar, e uma Reunio do Backlog do Portflio deve ser realizada para
determinar os prximos passos.
4. As Reunies do Backlog Priorizado do Produto do Portflio (tambm conhecidas como Reunies
do Backlog do Portflio), devem ser realizada em intervalos de 4 a 12 meses. Em grande parte, a
frequncia e o impacto de modificaes em um portflio determinam a durao de tempo entre
duas Reunies do Backlog do Portflio. Se existem vrias modificaes esperadas no portflio,
prefervel a realizao de Reunies do Backlog do Portflio em intervalos mais regulares (por
exemplo, de 4 a 6 meses), mas se existem poucas mudanas esperadas e se os requisitos so
estveis, a durao entre duas Reunies do Backlog do Portflio pode ser maior (por exemplo, de
9 a 12 meses).

6.6.2 Em Programa

1. No recomendado fazer mudanas em entre o perodo de duas Reunies do Backlog do


Programa.
2. Se a modificao for mnima, o Dono do Produto do Programa deve garantir a aprovao dos
stakeholders (patrocinador, cliente e usurio final) e em seguida, adicionar os requisitos no Backlog
do Programa. O Dono do Produto do projeto ir considerar estes requisitos para incluso em
Sprints futuros.
3. Se a mudana grande, os esforos do programa, juntamente com os programas, projetos e
Sprints associados, precisam parar, e uma Reunio do Backlog Priorizado do Produto do Programa
deve ser realizada para determinar os prximos passos.
4. As Reunies Backlog Priorizado do Produto do Programa (tambm conhecidas como Reunies do
Backlog do Programa), devem ser realizada em intervalos de 2 a 6 meses. Em grande parte, a

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 113


6 MUDANA

frequncia e o impacto de modificaes em um programa determinam a durao de tempo entre


duas Reunies do Backlog do Programa. Se existem vrias modificaes esperadas no programa,
prefervel a realizao de Reunies do Backlog do Programa em intervalos mais regulares (por
exemplo, de 2 a 3 meses), mas se existem poucas mudanas esperadas e se os requisitos so
estveis, a durao entre duas Reunies do Backlog do Programa poder ser maior (por exemplo,
de 5 a 6 meses).

A figura 6-8 demonstra como as mudanas podem ser gerenciadas dentro do fluxo do Scrum para ambos,
portflios e programas.

Figura 6-8: Incorporando Mudanas em Portflio e Programa

114 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


6 MUDANA

6.7 Resumo das Responsabilidades

Papel Responsabilidade
Scrum Guidance Fornecer a orientao geral para os procedimentos de gerenciamento de
Body mudanas a serem seguidos durante o projeto
Fornecer as Solicitaes de Mudana para o portflio
Dono do Produto do
Aprovar os produtos que sero alterados, removidos ou adicionados, de acordo
Portflio
com os requisitos do portflio
Scrum Master do Facilitar a identificao, avaliao e gerenciamento de Solicitaes de Mudana
Portflio para os portflios
Fornecer as Solicitaes de Mudana para o programa
Dono do Produto do
Programa
Aprovar os produtos que so alterados, removidos ou adicionados, de acordo 6
com os requisitos do programa
Scrum Master do Facilitar a identificao, avaliao e gerenciamento de Solicitaes de Mudana
Programa para os programas
Fornecer a solicitao de mudana
Stakeholder(s)
Envolvido com a aprovao e priorizao das Solicitaes de Mudana
Fornecer a solicitao de mudana de um projeto
Avaliar o impacto das solicitaes de mudana consideradas para o portflio,
programa ou projeto
Priorizar as Estrias de Usurio no Backlog Priorizado do Produto do projeto
Dono do Produto
Avaliar o impacto dos problemas nos objetivos do projeto identificados pelo
Time Scrum
Fornecer uma comunicao clara para os stakeholders sobre Itens
Repriorizados do Backlog do Produto
Facilitar a identificao, avaliao e escalabilidade dos problemas e das
Scrum Master
Solicitaes de Mudana pelo Time Scrum
Sugerir melhorias ou mudanas durante os processos de Criar as Entregas e
Time Scrum
Reunio Diria

Tabela 6-1: Resumo das Responsabilidades Relevantes de Mudana

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 115


6 MUDANA

6.8 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


O gerenciamento de mudana em modelos tradicionais de projeto est relacionado ao Gerenciamento de
Configurao. Todas as modificaes so consideradas com base em sua magnitude de variao, a partir
de um valor base. dado ao Gerente de Projeto as tolerncias dentro das quais, ele ou ela pode gerenciar
as atividades do dia-a-dia e as decises do projeto. Quando uma Solicitao de Mudana excede os limites
definidos, o Gerente de Projeto deve escalar a mudana proposta, para nveis mais elevados de gerncia e
aguardar pela deciso antes de iniciar a implementao. O Gerente de Projeto primeiro registra a
solicitao de mudana no Registro de incidente ou no Registro de Mudana, em seguida, transfere a
mudana para as autoridades superiores. Podendo incluir o patrocinador do projeto, bem como, os
stakeholders relevantes e os tomadores de deciso. Em algum momento, uma avaliao de impacto ser
realizada. Com base no impacto estimado da mudana, uma deciso ser tomada para determinar se a
mudana deve ser implementada ou no. O Gerente de Projeto tambm pode propor possveis solues
para os problemas causados pela mudana. Se a deciso tomada pelas autoridades superiores, para
prosseguir com a mudana, o Gerente de Projeto responsvel em garantir que a mudana ser
implementada corretamente.

A Mudana em Scrum funciona de uma forma muito diferente se comparada ao Modelo Tradicional de
Gerenciamento de Projeto. O framework Scrum altamente sintonizado para gerenciar mudanas com
eficcia e eficincia. Sempre que o Dono do Produto ou o Time Scrum encontram um problema ou defeito,
ou identificam um Item do Backlog Priorizado do Produto que precisa ser alterado, substitudo ou
adicionado, a modificao feita no Backlog Priorizado do Produto. Da mesma forma, a alta administrao,
o Dono do Produto, ou o(s) stakeholder(s) podem adicionar Solicitaes de Mudana para o Backlog
Priorizado do Produto. O Dono do Produto e o(s) Stakeholder(s) aprovam as Solicitaes de Mudana, e o
Backlog priorizado de acordo. Sempre que h um problema ou um novo requisito que precisa ser tratado
imediatamente e exige uma mudana que afeta o Sprint atual, o Dono do Produto encerra o Sprint com a
aprovao dos stakeholders relevantes. Uma vez encerrado, o Sprint vai ser replanejado e reiniciado para
incorporar os novos requisitos.

No entanto, se o problema ou a mudana no grande e no garante uma mudana no atual Sprint, a


modificao ser adicionada ao Backlog Priorizado do Produto e incorporada no planejamento de um Sprint
subsequente. Isto d aos stakeholders a habilidade de responder a mudanas no ambiente externo,
enquanto ainda mantido um certo grau de controle sobre as atividades do projeto em andamento. Alm
disso, no final de cada Sprint, os Entregveis Prontos so demonstrados pelo time Scrum. Estes
entregveis so potencialmente utilizveis e podem ser revisados pelo Dono do Produto e por outros
stakeholders.

116 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

7. RISCO

7.1 Introduo
O objetivo deste captulo definir riscos, discutir o gerenciamento de riscos em um ambiente Scrum, e
considerar as ferramentas que facilitam o gerenciamento de riscos. Para garantir a viabilidade do negcio,
reduzir a probabilidade de fracasso do projeto, e tomar decises de negcio mais informadas, importante
que os riscos sejam geridos de forma eficaz, atravs de uma abordagem bem organizada e metdica.

Em um ambiente Scrum os riscos so geralmente minimizados, em grande parte devido ao trabalho que
est sendo realizado nos Sprints, em que uma srie contnua de Entregveis produzido em ciclos muito
curtos, os Entregveis so comparados com as expectativas, e o Dono do Produto est ativamente
envolvido no projeto. No entanto, mesmo durante o projeto mais simples, as coisas podem dar errado, por
isso importante ter uma estratgia para identificar e direcionar os riscos. 7

Risco, conforme definido em Um Guia para o Conhecimento em Scrum (Guia SBOK), aplicvel a:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Este captulo est dividido nas seguintes sees:

7.2 Guia dos PapisEsta seo fornece orientao sobre quais sees so relevantes para cada papel
do Scrum: Dono do Produto, Scrum Master e Time Scrum.

7.3 O que Risco?Esta seo define o risco e explica como o mesmo pode afetar os objetivos de um
projeto e contribuir para o seu sucesso ou fracasso.

7.4 Procedimento no Gerenciamento de RiscosEsta seo apresenta as principais tcnicas de


gerenciamento de risco e elabora o desenvolvimento de estratgias para identificar, avaliar e gerir os riscos.

7.5 Minimizao de Riscos Atravs do ScrumEsta seo explica os principais aspectos do Scrum, que
o tornam um framework de gerenciamento ideal para lidar os riscos de forma eficaz em vrios nveis:
portflio, programa e projeto.

7.6 Resumo das ResponsabilidadesEsta seo descreve as responsabilidades de cada pessoa ou do


papel em um projeto com relao ao gerenciamento de riscos.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 117


7 RISCO

7.7 Scrum x O Modelo Tradicional de Gerenciamento de ProjetosEsta seo discute os benefcios do


gerenciamento de risco, utilizando mtodos do Scrum, em relao aos mtodos utilizados nos modelos
tradicionais de gerenciamento de projetos.

7.2 Guia dos Papis


1. Dono do ProdutoO Dono do Produto o principal responsvel em lidar com os riscos de um
projeto, portanto, todo este captulo mais aplicvel a este papel.

2. Scrum MasterO Scrum Master deve estar familiarizado com este captulo inteiro, com foco
principal nas sees 7.3, 7.4 e 7.7.

3. Time ScrumO Time Scrum deve se concentrar principalmente nas sees 7.3 e 7.7.

7.3 O que Risco?


Risco definido como um evento incerto que pode afetar os objetivos de um projeto e podem contribuir
para o seu sucesso ou fracasso. Os riscos com o potencial de causar um impacto positivo sobre o projeto
so conhecidos como oportunidades, enquanto que as ameaas so os riscos que podem afetar o projeto
de uma forma negativa. A gesto de riscos deve ser feita de forma proativa, e um processo iterativo que
deve comear no incio do projeto e continuar ao longo de seu ciclo de vida. O processo de gerenciamento
de riscos deve seguir alguns passos padronizados para garantir que os riscos sejam identificados,
avaliados, e que um plano de ao seja definido e colocado em prtica apropriadamente.

Os riscos devem ser identificados, avaliados e respondidos com base em dois fatores: a probabilidade de
ocorrncia de cada risco, e o impacto potencial em caso de tal ocorrncia. Os riscos de alta probabilidade e
valor impactante devem ser tratados antes do que os com valor relativamente menor. Em geral, uma vez
que o risco identificado, importante compreender suas possveis causas e potenciais efeitos caso este
venha acontecer

7.3.1 Diferena entre Riscos e Problemas

Os riscos so as incertezas relacionadas a um projeto, que podem alterar significativamente o resultado do


projeto de uma forma positiva ou negativa. Como os riscos so as incertezas futuras, no tm impacto atual
no projeto, mas podem ter um impacto potencial no futuro. A seguir, alguns exemplos de riscos:

Mesmo depois de um treinamento intenso, os representantes (usurios) do servio ao cliente


podem no estar preparados para emitir pedidos na data do go-live (implantao).

118 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

A equipe de pintura pode se atrasar devido uma forte chuva, o que pode impactar negativamente o
cronograma do projeto.

Os problemas so geralmente certezas bem definidas, que esto acontecendo atualmente no projeto, por
isso no h necessidade de se realizar uma avaliao de probabilidade, como seria feito para um risco. Os
problemas devem ser tratados. Alguns exemplos de problemas:

O financiamento no foi aprovado.


Os requisitos no esto claros.

Se os riscos no forem tratados a tempo, podem se tornar problemas. O objetivo do gerenciamento de


riscos estar preparado com planos que tomem conta dos riscos que possam ocorrer.

7.3.2 Atitude de Riscos


7
Os stakeholders incluem todas as pessoas ou organizaes afetadas pelo projeto, bem como aqueles que
tm a capacidade de afetar o projeto. importante entender a atitude de risco dos stakeholders. A atitude
de risco influenciada por trs fatores:

1. Apetite de riscos: refere-se a quantidade de incerteza que um stakeholder ou uma organizao


est disposta a assumir.
2. Tolerncia aos riscos: indica o grau, quantidade ou volume de risco ao qual os stakeholders iro
resistir.
3. Limite de riscos: refere-se ao nvel aceitvel de risco para uma organizao. Um risco cair acima
ou abaixo da Limite de Riscos. Se estiver abaixo, o stakeholder ou a organizao estaro mais
propensos a aceitar o risco.

Essencialmente, a atitude de risco dos stakeholders determina quanto risco eles consideram aceitvel, e
consequentemente, quando eles decidirem tomar aes para atenuar potenciais riscos adversos. Portanto,
importante entender os nveis de tolerncia dos stakeholders, em relao a vrios fatores, incluindo custo,
qualidade, escopo e cronograma.

Funo de Utilidade um modelo usado para medir a preferncia de risco do stakeholder ou sua atitude em
relao ao risco. As trs categorias de funo de utilidade so:

1. Averso a risco: O stakeholder no est disposto a aceitar um risco, independentemente de seu


benefcio ou oportunidade.
2. Risco neutro: O stakeholder no se ope ao risco mas tambm no demostra interesse pelo
mesmo; qualquer deciso no afetada pelo nvel de incerteza do resultado. Quando dois cenrios
possveis apresentam o mesmo nvel de benefcio, o stakeholder de risco neutro no vai se
preocupar se um cenrio mais arriscado do que o outro.
3. Buscando o risco: O stakeholder est disposto a aceitar o risco, mesmo que este proporcione uma
margem de aumento em retorno ou benefcio para o projeto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 119


7 RISCO

7.4 Procedimento no Gerenciamento de Riscos


O Gerenciamento de Riscos consiste em cinco etapas:

1. Identificao de riscos: a utilizao de vrias tcnicas, para identificar todos os riscos potenciais.
2. Avaliao de riscos: avaliar e estimar os riscos identificados.
3. Priorizao de riscos: a priorizao de riscos que sero includos no Backlog Priorizado do
Produto.
4. Mitigao de riscos: o desenvolvimento de uma estratgia adequada para lidar com o risco.
5. Comunicao de riscos: a comunicao dos resultados das quatro primeiras etapas aos
stakeholders apropriados, e a determinao de sua percepo sobre os eventos incertos.

7.4.1 Identificao de Riscos

Os membros do Time Scrum devem tentar identificar todos os riscos que possam afetar o projeto. Este
trabalho apenas pode ser realizado por completo, quando os membros do time passam a olhar para o
projeto, a partir de perspectivas diferentes, e a utilizar vrias tcnicas. A Identificao de Riscos feita ao
longo do projeto e riscos identificados se tornam entradas para vrios processos Scrum, incluindo: Criar o
Backlog Priorizado do Produto, Refinamento do Backlog Priorizado do Produto, e Demonstrar e Validar o
Sprint.

As seguintes tcnicas so comumente usadas para identificar os riscos.

7.4.1.1 As Tcnicas de Identificao de Riscos

1. Rever as Lies Aprendidas nos Processos de Retrospectiva do Sprint ou de Retrospectiva


do Projeto

Aprender com projetos similares e Sprints anteriores dos mesmos, e explorar as incertezas que
afetaram esses projetos e Sprints pode ser uma maneira til para identificar os riscos.

2. Checklists de Risco

Os Checklists de Risco podem incluir os pontos-chave a serem considerados ao identificar os


riscos, os riscos comuns encontrados em projetos Scrum, ou at mesmo as categorias de riscos
que devem ser abordados pelo time. Os Checklists so uma ferramenta valiosa, ajudando a
garantir a identificao abrangente de risco.

120 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

3. Listas de Risco Prompt

As Listas de Risco Prompt so usadas para estimular pensamentos sobre a fonte de origem dos
riscos. As Listas de Risco Prompt de vrios tipos de indstrias e de projetos esto disponveis ao
pblico.

4. Brainstorming

So sesses onde os stakeholders e os membros do Time Central do Scrum, abertamente


compartilham ideias, atravs de debates e sesses de compartilhamento de conhecimento, que
normalmente so conduzidos por um facilitador.

5. Estrutura Analtica de Risco (EAR)

Uma das principais ferramentas utilizadas na identificao de riscos uma estrutura analtica dos
riscos. Nesta estrutura, os riscos so agrupados de acordo com suas categorias ou semelhanas.
Por exemplo, os riscos podem ser categorizados como financeiros, tcnicos, ou relacionados a
7
segurana. Isso permite que o time planeje e trate cada risco da melhor maneira.

7.4.1.2 Risk-Based Spike

Um conceito que pode ser til na identificao de riscos o de risk-based spike. O spike um experimento
que envolve pesquisa ou um prottipo para um melhor entendimento de riscos potenciais. Em um spike,
conduzido um exerccio intenso com durao de dois ou trs dias (preferencialmente no incio do projeto
(antes dos processos de Desenvolver os pico(s) ou Criar o Backlog Priorizado do Produto), para ajudar o
time a determinar as incertezas que possam afetar o projeto. Risk-based spikes so teis quando o Time
Scrum est trabalhando (ou se acostumando) com novas tecnologias ou ferramentas, ou quando as
Estrias de Usurio so longas. Tambm ajudam na estimativa mais precisa de tempo e de esforo.

7.4.2 Avaliao de Riscos

A avaliao de riscos ajuda a compreender o impacto potencial de um risco, qual sua a probabilidade de
ocorrncia e quando o risco pode se materializar. O efeito geral sobre o valor do negcio deve ser estimado
se esse impacto for significante o suficiente para compensar a justificativa de negcio, uma deciso deve
ser tomada com relao continuidade do projeto.

A avaliao dos riscos feita com relao probabilidade, proximidade e impacto. A probabilidade de
riscos refere-se probabilidade de ocorrncia dos riscos, enquanto que a proximidade se refere a, quando
que o risco pode ocorrer. O impacto refere-se ao efeito provvel dos riscos no projeto ou na organizao.

Para estimar a probabilidade de um risco, vrias tcnicas podem ser utilizadas, incluindo: rvores de
Probabilidade, Anlise de Pareto, e Matriz de Probabilidade e de Impacto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 121


7 RISCO

Alm da probabilidade, a avaliao de risco tambm avalia o efeito lquido potencial dos riscos sobre o
projeto ou organizao. Estes efeitos podem ser estimados usando tcnicas como: Modelos de Risco e
Valor Monetrio Esperado.

7.4.2.1 As Tcnicas de Avaliao de Risco

1. Reunio de Risco

Os riscos podem ser mais facilmente priorizados pelo Dono do Produto ao convocar uma reunio
com o Time Central do Scrum e, opcionalmente, convidando os Stakeholders relevantes. O Time
pode se reunir, e priorizar diferentes riscos com base em sua avaliao subjetiva do impacto dos
riscos nos objetivos do projeto.

2. rvores de Probabilidade

Os eventos potenciais so representados em uma rvore com um ramo para cada resultado
possvel dos eventos. A probabilidade de cada resultado indicado no ramo apropriado e, em
seguida, multiplicada pelo seu impacto avaliado, para obter um valor esperado para a
possibilidades de cada resultado. Os valores de resultado so ento somados para calcular o
impacto geral esperado de um risco para um projeto (veja a figura 7-1).

Figura 7-1: Exemplo da rvore de Probabilidade

122 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

3. Anlise de Pareto

Essa tcnica de avaliao de risco envolve a classificao de riscos por magnitude, o que ajuda o
Time Scrum a tratar dos riscos, na ordem de seus possveis impactos sobre o projeto. Por
exemplo, na figura 7-2, o Risco nmero 1 tem o maior impacto e deve ser, preferencialmente, o
primeiro a ser tratado.

Figura 7-2: Exemplo do Grfico de Pareto

4. Tabela de Probabilidade e de Impacto

Cada risco avaliado a partir de sua probabilidade de ocorrncia e do impacto potencial sob os
objetivos do projeto. Geralmente, um valor numrico atribudo de forma independente tanto para
probabilidade quanto para o impacto. Em seguida, os dois valores so multiplicados, para se obter
uma escala de gravidade de risco (o valor do PI), o que pode ser usado para dar prioridade aos
riscos.

Por exemplo, a pontuao da gravidade de um risco com uma probabilidade de 50% e com uma
classificao de impacto de 0,6 deve ser calculado da seguinte forma:

0.5(Probabilidade) x 0.6(Impacto) = 0.3

Os esquemas de classificao utilizados so determinados dentro da organizao ou para o


projeto. Muitas vezes, uma escala decimal utilizada, de 0 a 1, em que uma classificao de 0,5
indicar a probabilidade uma de 50%. Outras opes incluem uma escala de 1 a 10, ou de Alta (3),
Mdia (2), e Baixa (1).

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 123


7 RISCO

A figura 7-3 representa a utilizao da escala decimal. Cada risco classificado em sua probabilidade
de ocorrncia e impacto em uma escala objetiva.

Matriz de Probabilidade e Impacto

Ameaas Oportunidades
0.90 0.09 0.27 0.72 0.72 0.27 0.09
Probabilidade

0.75 0.075 0.225 0.60 0.60 0.225 0.075

0.50 0.05 0.15 0.40 0.40 0.15 0.05

0.30 0.03 0.09 0.24 0.24 0.09 0.03

0.10 0.01 0.03 0.08 0.08 0.03 0.01


Baixo Alto Alto Baixo
Mdio 0.3 Mdio 0.3
0.1 0.8 0.8 0.1

Impacto

Baixo valor PI Mdio valor PI Alto valor PI

Figura 7-3: Exemplo da Matriz de Probabilidade e Impacto

O mtodo de atribuio de valores de probabilidade e de impacto de riscos varia de acordo com o


projeto e o nmero de riscos a serem avaliados, bem como os processos e procedimentos
organizacionais existentes. No entanto, atravs da aplicao simples da frmula P x I, a gravidade
do risco pode ser calculada em uma escala numrica ou categrica.

5. Valor Monetrio Esperado (VME)

O valor monetrio do risco baseado em seu Valor Monetrio Esperado (VME). O VME
calculado multiplicando o impacto monetrio pela probabilidade do risco, de acordo com a
aproximao feita pelo cliente.

Valor Monetrio Esperado = Impacto de Risco (em reais) x Probabbilidade do Risco (porcentagem)

Por exemplo, um risco com um impacto negativo estimado de R$ 1.000,00 e uma probabilidade de
ocorrncia de 50%, resultaria em um VME igual:

VME = R$1.000.00 x 0.50 = R$500

124 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

7.4.3 Priorizao de Riscos

O Scrum permite a rpida identificao e avaliao dos riscos. Os Riscos Identificados so considerados na
criao do Backlog Priorizado do Produto durante o processo de Criar o Backlog Priorizado do Produto, ou
quando atualizamos o Backlog Priorizado do Produto durante o processo de Refinamento do Backlog
Priorizado do Produto. Neste caso um Backlog Priorizado do Produto tambm pode ser referido como um
Backlog Priorizado do Produto com o Risco Ajustado.

Os riscos podem ser identificados e avaliados com base em qualquer uma das tcnicas de Identificao de
Riscos e Avaliao de Riscos mencionadas anteriormente.

Nos processos de Criar o Backlog Priorizado do Produto ou de Refinamento do Backlog Priorizado do


Produto, as Estrias de Usurio priorizadas a partir do Backlog Priorizado do Produto existente e a lista
priorizada de riscos so ento, combinadas para criar um Backlog do Produto Priorizado e Atualizado que
inclui os Riscos Identificados:

Passos para a atualizao de um Backlog Priorizado do Produto, com os Riscos Identificados: 7

1. Crie uma lista de riscos priorizados. Por exemplo, os riscos podem ser priorizados de acordo com o
seu valor, utilizando a tcnica de Valor Monetrio Esperado.

2. Selecione os Riscos Identificados que podem ser mitigados; e para os quais o time decide tomar
medidas especficas de risco durante o Sprint, para mitigar tais riscos.

3. Crie uma lista de Estrias de Usurio no Backlog Priorizado do Produto, que sejam priorizadas pelo
valor. Por exemplo, o valor de cada Estria de Usurio pode ser avaliada com base no seu Retorno
sobre Investimento esperado.

4. Combine as listas do passo 2 e passo 3 e as priorize pelo valor, para chegar ao Backlog do
Produto Priorizado e Atualizado.

A figura 7-4 ilustra o processo de priorizao de risco.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 125


7 RISCO

Figura 7-4: Processo para a Priorizao de Risco

7.4.4 Mitigao de Riscos

A resposta a cada um dos riscos vai depender da probabilidade e impacto dos riscos. No entanto, a
natureza iterativa do Scrum com seus ciclos rpido de tempo e feedback, permite a deteco precoce de
falhas, portanto, na prtica, j possui uma caracterstica natural de mitigao.

O risco pode ser mitigado atravs da implementao de uma srie de respostas. Na maioria dos casos, as
respostas so proativas ou reativas. No caso de um risco, um plano B pode ser formulado, que pode ser
utilizado caso o risco venha a se materializar. Este plano B considerado uma resposta reativa. s vezes,
os riscos so aceitos e so um exemplo de uma resposta ao risco que no proativa nem reativa. Os riscos
so aceitos por vrias razes, como em uma situao em que a probabilidade ou impacto do risco seja
muito baixa, no sendo necessrio nenhuma reao. A aceitao tambm pode ser resultar em uma
situao onde a apreenso de riscos secundrios podem dissuadir o Dono do Produto de tomar qualquer
ao. O esforo feito pelo Dono do Produto, para reduzir a probabilidade ou impacto, do risco, ou ambos,
um exemplo de resposta proativa para a mitigao de riscos.

Uma vez que os Riscos Identificados sejam includos como parte do Backlog Priorizado do Produto (veja a
figura 7-4), vrios riscos so mitigados durante o processo de Criar os Entregveis quando as Tarefas
relacionadas com as Estrias de Usurio definidas no processo do Backlog Priorizado do Produto so
concludas.

126 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

Em Scrum, o Dono do Produto claramente responsvel pelo gerenciamento de riscos relacionados a


aspectos do negcio e o Time Scrum responsvel pela implementao de respostas aos riscos, durante o
desenvolvimento de um Sprint. O Scrum Guidance Body pode ser abordado para dar conselhos sobre a
forma como as respostas aos riscos devem ser implementadas, e se as aes esto de acordo com as
diretrizes da organizao como um todo. O Scrum Master mantm-se atento aos potenciais riscos que
possam afetar o projeto e mantm informado o Dono do Produto e o Time Scrum.

7.4.5 Comunicao de Riscos

Pelo fato de que os stakeholders tm interesse no projeto, importante comunic-los sobre os riscos. As
informaes fornecidas aos stakeholders relacionadas ao risco devem incluir o impacto potencial e os
planos de resposta para cada risco. Esta comunicao deve ser permanente e deve ocorrer em paralelo
com as quatro etapas sequenciais discutidas at agora (identificao, avaliao, priorizao e mitigao de
risco). O Time Scrum tambm pode discutir os riscos especficos relacionados s suas tarefas com o Scrum
Master durante as Reunies Dirias. O Dono do Produto responsvel pela priorizao de riscos e pela
7
comunicao da lista de prioridades ao Time Scrum.

O Grfico burndown de Risco uma ferramenta importante que pode ser utilizada na comunicao de
informaes relacionadas aos riscos.

7.4.5.1 Grfico de Risco Burndown

O gerenciamento de risco essencial para garantir a criao de valor, portanto, as atividades de


gerenciamento de risco so realizadas ao longo do ciclo de vida do projeto e no apenas durante o seu
incio.

Cada risco pode ser avaliado atravs da utilizao de diferentes ferramentas de Avaliao de Risco. No
entanto, a ferramenta preferida para avaliar os riscos, para criar um Grfico de Risco Burndown o Valor
Monetrio Esperado (VME), conforme descrito na seo 7.4.2.1.

As informaes coletadas durante a avaliao de risco podem ser usadas para criar um Grfico de Risco
Burndown. Isto descreve a gravidade de risco do projeto cumulativo ao longo do tempo. As probabilidades
dos diversos riscos so posicionados em cima uns dos outros para mostrar risco cumulativo sobre o eixo-y.
A identificao e avaliao inicial de riscos sobre o projeto, e a criao do Grfico de Risco Burndown so
feitas inicialmente. Em seguida, em intervalos de tempo pr-determinados, novos riscos podem ser
identificados e avaliados, os riscos restantes devem ser reavaliados e atualizados de acordo com o grfico.
Um momento oportuno para fazer isso durante a Reunio de Planejamento do Sprint. O rastreamento
riscos desta forma, permite que o time possa reconhecer as tendncias da exposio ao risco e tomar
medidas adequadas, caso necessrio.

A figura 7-5 mostra um exemplo de um Grfico de Risco Burndown.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 127


7 RISCO

Figura 7-5: Exemplo do Grfico de Risco Burndown

7.5 Minimizao de Riscos Atravs do Scrum


Sendo um processo iterativo de gil, o framework Scrum inerentemente minimiza o risco. As seguintes
prticas do Scrum facilitam o gerenciamento eficaz de risco:

1. A flexibilidade reduz o risco de negcio relacionado com o ambiente


O risco , em grande parte minimizado em Scrum, devido flexibilidade de adicionar ou modificar
requisitos a qualquer momento durante o ciclo de vida do projeto. Isso permite que a organizao
possa responder s ameaas ou oportunidades do ambiente de negcios e as necessidades
imprevistas, sempre que surgirem, geralmente com custo baixo de gerenciamento.

2. O Feedback regular reduz as expectativas relacionadas com o risco


Sendo iterativo, o framework Scrum d ampla oportunidade para a obteno de feedback e
definio de expectativas ao longo do ciclo de vida do projeto. Isso garante que os stakeholders do
projeto, bem como o time, no sejam pegos de surpresa por m comunicao relacionada aos
requisitos.

3. A posse do time reduz o risco de estimativa


O Time Scrum estima, e responsvel pelos Itens do Backlog do Sprint, o que leva a estimativa
mais precisa e a entrega oportuna de incrementos do produto.

128 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

4. A transparncia reduz os riscos no detectados


O princpio de transparncia do Scrum, em torno do qual o framework Scrum construdo, garante
que os riscos sejam detectados e comunicados no incio, levando a um melhor tratamento e
mitigao de riscos. Alm disso, quando as Reunies do Scrum de Scrums realizada, os
impedimentos que um time est enfrentando atualmente, podem ser considerados um risco para
outros Times Scrum no futuro. Isso deve ser identificado no Registro de Impedimentos Atualizado.

5. A entrega iterativa reduz o risco de investimento


A entrega contnua de valor durante todo o ciclo de vida do projeto Scrum, conforme so criados os
entregveis potencialmente utilizveis depois de cada Sprint, reduz o risco de investimento para o
cliente.

7.6 Riscos em Portflios e Programas


7
Enquanto alguns riscos esto especificamente relacionados com projetos individuais, outros podem ter
origem em programas ou portflios e geralmente serem gerenciados nos mesmos. No entanto, os riscos
relacionados a um portflio ou programa tambm impactaro os projetos que fazem parte do respectivo
portflio ou programa. Durante a avaliao de riscos em portflios e programas, se for determinado que um
risco poder afetar um projeto individual, informaes relevantes ao risco devero ser comunicadas ao
Dono do Produto e ao Time Scrum.

Dependendo da gravidade ou prioridade, quando o time do programa ou portflio comunica um risco que ir
impactar um projeto individual, o Time Scrum pode ter que parar e re-planejar o Sprint atual, para tratar o
risco. Para riscos de menor urgncia, o time pode continuar o Sprint atual e tratar o risco em um Sprint
subsequente.

7.6.1 Em Portflio

1. Quando os riscos em Portflio so identificados, o Dono do Produto do Portflio dever capturar e


avaliar a, proximidade, probabilidade e o impacto de cada risco identificado, a fim de prioriz-los e
de determinar a resposta apropriada para o portflio.

2. O Dono do Produto do Portflio tambm precisar comunicar os riscos aos stakeholders


relevantes, aos times do programa e aos times do projeto. Em alguns casos, o time do portflio
pode ter que assumir a responsabilidade de riscos especficos.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 129


7 RISCO

7.6.2 Em Programa

1. Quando os riscos do programa so identificados, o Dono do Produto do Programa deve inseri-los


no Backlog Priorizado do Produto de Risco Ajustado do programa, avaliar a proximidade,
probabilidade e o impacto de cada risco identificado, a fim de prioriz-los e de determinar as
respostas adequadas para os programas.

2. O Dono do Produto do Programa tambm precisar comunicar os riscos aos stakeholders


relevantes e aos times do projeto. Em alguns casos, o time do programa pode ter que assumir a
responsabilidade de riscos especficos.

A figura 7-6 demonstra como os riscos podem ser gerenciados dentro do fluxo Scrum para os portflio e
programas.

Figura 7-6: O Manuseio de Riscos em Portflios e Programas

130 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


7 RISCO

7.7 Resumo das Responsabilidades


Em Scrum, as atividades de gerenciamento de risco so divididas entre vrios papis, sendo que algumas
responsabilidades so de todos os membros do Time Scrum, enquanto que o Scrum Master facilita o
processo.

Papis Responsabilidades
Fornecer orientao geral para o procedimento de gerenciamento de risco a
Scrum Guidance Body
ser seguido durante o projeto
Capturar e avaliar os riscos para os portflios
Dono do Produto do
Priorizar e comunicar os riscos para os stakeholders, programa, e times do
Portflio
projeto
Scrum Master do
Facilitar a identificao, avaliao e comunicao de riscos para os portflios
Portflio
7
Dono do Produto do Capturar e avaliar os riscos para os programas
Programa Priorizar e comunicar os riscos para os stakeholders e times do projeto
Scrum Master do
Facilitar a identificao, avaliao e comunicao de riscos para os programas
Programa
Interagir com o Time Central do Scrum para lhes fornecer inputs sobre o
Stakeholder(s) gerenciamento de riscos que afetam a obteno dos resultados e benefcios
esperados do projeto
Capturar e avaliar os riscos para o projeto
Priorizar e comunicar os riscos para os stakeholders, programa e times do
Dono do Produto
portflio
Garantir que os nveis de risco do projeto esto dentro dos limites aceitveis
Scrum Master Facilitar a identificao e a classificao de riscos pelo Time Scrum
Identificar os riscos durante o desenvolvimento do produto no processo de
Criar os Entregveis
Time Scrum
Implementar atividades de gerenciamento de risco, como aconselhado pelo
Dono do Produto

Tabela 7-1: Resumo das Responsabilidades Relevantes de Risco

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 131


7 RISCO

7.8 Scrum x O Modelo Tradicional de Gerenciamento de Projetos


O Scrum e a maioria dos mtodos tradicionais de gerenciamento de projeto definem o risco como
"evento(s) incerto(s) que podem afetar positivamente ou negativamente a consecuo dos objetivos do
projeto." Alm disso, os riscos so continuamente identificados, avaliados, planejados e comunicados.

Nos modelos tradicionais de gerenciamento de projeto, h nfase no planejamento inicial detalhado para
identificar, avaliar e determinar as respostas de risco para todos os riscos do projeto. Durante a execuo
do projeto, qualquer membro do time do projeto pode identificar riscos, e a sua atualizao pode ser feita
pelo gerente de projeto, pelo escritrio de gerenciamento de projeto ou pelo time de apoio do projeto, no
Registro de Risco. O gerente de projeto monitora e controla regularmente todos os riscos e geralmente
identifica os indivduos especficos do time que devem assumir a responsabilidade por diferentes aspectos
de riscos.

Em Scrum, qualquer membro do Time Scrum pode identificar riscos e o Dono do Produto pode atualizar os
riscos identificados, no Backlog Priorizado do Produto de Risco Ajustado. Os princpios do Scrum de
Controle de Processo Emprico e de Desenvolvimento Iterativo permitem que o Time Scrum possa manter
constantemente a identificao de riscos, e de adicion-los ao Backlog Priorizado do Produto, onde esses
riscos sero priorizados juntamente com outras Estrias de Usurios existentes no backlog, para serem
mitigados em Sprints seguintes. O Time Scrum tem responsabilidades coletivas no gerenciamento de todos
os riscos no Sprint.

132 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8. INICIAR
Este captulo inclui os processos relacionados ao incio de um projeto: Criar a Viso do Projeto, Identificar o
Scrum Master e Stakeholder(s), Formar o Time Scrum, Desenvolver o(s) pico(s), Criar o Backlog
Priorizado do Produto e Conduzir o Planejamento de Releases.

Iniciar, conforme definido em Um Guia para o Conhecimento em Scrum (Guia SBOK), aplicvel a:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou qualquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.
8
Para facilitar a melhor aplicao do framework Scrum, este captulo identifica as entradas, ferramentas e
sadas de cada processo como "obrigatrias" ou "opcionais". As entradas, ferramentas e sadas, indicadas
por asteriscos (*), so obrigatrias, enquanto que as sem asteriscos, so opcionais.

Recomenda-se que o Time Scrum e os indivduos que esto sendo introduzidos aos processos e framework
Scrum, concentrem-se principalmente nas entradas, ferramentas e sadas obrigatrias; enquanto que os
Donos do Produto, Scrum Masters, e outros profissionais mais experientes em Scrum, devem esforar-se
para obter um conhecimento mais profundo da informao contida neste captulo inteiro. Tambm
importante perceber que, apesar de todos os processos serem definidos exclusivamente no Guia SBOK,
eles no so necessariamente realizados sequencialmente ou separadamente. As vezes, pode ser mais
conveniente combinar alguns processos, dependendo dos requisitos especficos de cada projeto.

Este captulo escrito a partir da perspectiva de um Time Scrum, que est trabalhando em um Sprint, para
produzir os Entregveis potencialmente utilizveis, como parte de um projeto maior. No entanto, a
informao descrita igualmente aplicvel a projetos, programas e portflios inteiros. As informaes
adicionais relativas utilizao do Scrum para projetos, programas e portflios esto disponveis do
captulo 2 ao 7, que abrangem os princpios do Scrum e os aspectos do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 133


8 INICIAR

A figura 8-1 fornece uma viso geral dos processos da fase Iniciar, que so os seguintes:

8.1 Criar a Viso do ProjetoNeste processo, o Caso de Negcio do Projeto revisado para criar uma
Declarao da Viso do Projeto que servir de inspirao e orientao para todo o projeto. O Dono do
Produto identificado nesse processo.

8.2 Identificar o Scrum Master e o(s) Stakeholder(s)Nesse processo, o Scrum Master e os


stakeholders so identificados, utilizando Critrios de Seleo especficos.

8.3 Formar o Time ScrumNesse processo, os membros do Time Scrum so identificados. Normalmente,
o Dono do Produto tem a responsabilidade de selecionar os membros do time, porm, muitas vezes conta
com a colaborao do Scrum Master.

8.4 Desenvolver o(s) pico(s)Nesse processo, a Declarao da Viso do Projeto serve como base para
o desenvolvimento dos picos. As Reunies dos Grupos de Usurios podem ser realizadas para discutir
picos apropriados.

8.5 Criar o Backlog Priorizado do ProdutoNesse processo, os picos so refinados e elaborados, e em


seguida priorizados, para criar o Backlog Priorizado do Produto para o projeto. Os Critrios de Pronto
tambm so estabelecidos neste ponto.

8.6 Conduzir o Planejamento da ReleaseNesse processo, o Time Central do Scrum analisa as Estrias
de Usurio no Backlog Priorizado do Produto para desenvolver um Cronograma de Planejamento da
Release, que essencialmente, um cronograma de implantao por fases que pode ser compartilhado com
os Stakeholders. O tamanho dos Sprints tambm determinado durante esse processo.

134 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.1 Criar a Viso do Projeto 8.2 Identificar o Scrum Master e o 8.3 Formar o Time Scrum
Stakeholder(s)
ENTRADAS ENTRADAS ENTRADAS
1. Caso de Negcio do Projeto* 1. Dono do Produto* 1. Dono do Produto*
2. Dono do Produto do Programa 2. Declarao da Viso do Projeto* 2. Scrum Master*
3. Scrum Master do Programa 3. Dono do Produto do Programa 3. Declarao da Viso do Projeto*
4. Stakeholder(s) do Programa 4. Scrum Master do Programa 4. Dono do Produto Chefe
5. Dono do Produto Chefe 5. Dono do Produto Chefe 5. Requisito de Pessoal
6. Backlog do Produto do Programa 6. Scrum Master Chefe 6. Comprometimento e Disponibilidade de
7. Julgamento do Projeto 7. Stakeholder(s) do Programa Pessoal
8. Prova de Conceito 8. Requisito de Pessoal 7. Matriz de Recurso Organizacional
9. Viso da Empresa 9. Comprometimento e Disponibilidade de 8. Matriz de Requisito de Habilidades
10. Misso da Empresa Pessoal 9. Requisito de Recursos
11. Estudo de Mercado 10. Matriz de Recurso Organizacional 10. Recomendaes do Scrum Guidance
12. Recomendaes do Scrum Guidance 11. Matriz de Requisito de Habilidades Body
Body 12. Recomendaes do Scrum Guidance FERRAMENTAS
FERRAMENTAS Body 1. Seleo do Time Scrum*
1. Reunio da Viso do Projeto* FERRAMENTAS 2. Conselho de Especialista do RH
2. Sesses JAD 1. Critrios de Seleo* 3. Custo de Pessoal
3. Anlise SWOT 2. Conselho de Especialista do RH 4. Trainamento e Custos de Treinamento
4. Anlise de Gap 3. Treinamento e Custos de Treinamento 5. Custos de Recurso
SADAS 4. Custos de Recurso SADAS
1. Dono do Produto Identificado* SADAS 1. Time Scrum Identificado*
2. Declarao da Viso do Projeto* 1. Scrum Master Identificado* 2. Pessoa para Backup 8
3. Termo de Abertura do Projeto 2. Stakeholder(s) (so) Identificado(s)* 3. Plano de Colaborao
4. Oramento do Projeto 4. Plano de Team Building

8.4 Desenvolver o(s) pico(s) 8.5 Criar o Backlog Priorizado do 8.6 Conduzir o Planejamento da
Produto Release
ENTRADAS ENTRADAS ENTRADAS
1. Time Central do Scrum* 1. Time Central do Scrum* 1. Time Central do Scrum*
2. Declarao da Viso do Projeto* 2. pico(s)* 2. Stakeholder(s)*
3. Stakeholder(s) 3. Personas* 3. Declarao da Viso do Projeto*
4. Backlog do Produto do Programa 4. Stakeholder(s) 4. Backlog Priorizado do Produto*
5. Solicitaes de Mudana Aprovadas 5. Declarao da Viso do Projeto 5. Critrio de Pronto*
6. Solicitaes de Mudana No 6. Backlog do Produto do Programa 6. Dono do Produto do Programa
Aprovadas 7. Requisitos de Negcio 7. Scrum Master do Programa
7. Riscos de Programa e de Portflio 8. Solicitaes de Mudana Aprovadas 8. Dono do Produto Chefe
8. Leis e Regulamentos 9. Riscos Identificados 9. Backlog do Produto do Programa
9. Contratos Aplicveis 10. Contratos Aplicveis 10. Requisitos de Negcio
10. Informaes sobre o Projeto Anterior 11. Recomendaes do Scrum Guidance 11. Calendrio de Feriados
11. Recomendaes do Scrum Guidance Body Recomendaes do Scrum Guidance
Body Body
FERRAMENTAS
FERRAMENTAS 1. Mtodos de Priorizao da Estria de FERRAMENTAS
1. Reunies dos Grupos de Usurios* Usurio* 1. Sesses do Planejamento da Release*
2. Workshops da Estria de Usurio 2. Workshop de Estrias de Usurio 2. Mtodos de Priorizao da Release*
3. Reunies do Grupo de Foco 3. Planejamento ou Valor SADAS
4. Entrevistas com o Usurio ou Cliente 4. Tcnicas de Avaliao de Risco 1. Cronograma de Planejamento da
5. Questionrios 5. Estimativa do Valor do Projeto Release*
6. Tcnicas de Identificao de Riscos 6. Mtodos de Estimativa da Estria de 2. Durao do Sprint*
7. Expertise do Scrum Guidance Body Usurio 3. Clientes-alvo para a Release
SADAS 7. Expertise do Scrum Guidance Body 4. Backlog do Produto Priorizado e
1. pico(s)* SADAS Refinado
2. Personas* 1. Backlog Priorizado do Produto*
3. Mudanas Aprovadas 2. Critrio de Pronto*
4. Riscos Identificados
Figura 8-1: A Viso Geral de Iniciar
Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 135


8 INICIAR

A figura 8-2 abaixo mostra as entradas, ferramentas e sadas obrigatrias para os processos da fase Iniciar.

8.1 Criar a Viso do Projeto 8.2 Identificar o Scrum Master e 8.3 Formar o Time Scrum
o Stakeholder(s)

ENTRADAS ENTRADAS ENTRADAS


1. Caso de Negcio do Projeto* 1. Dono do Produto* 1. Dono do Produto*
FERRAMENTAS 2. Declarao da Viso do Projeto* 2. Scrum Master*
1. Reunio da Viso do Projeto* FERRAMENTAS 3. Declarao da Viso do Projeto*
SADAS 1. Critrios de Seleo* FERRAMENTAS
1. Dono do Produto Identificado* SADAS 1. Seleo do Time Scrum*
2. Declarao da Viso do Projeto* 1. Scrum Master Identificado* SADAS
2. Stakeholder(s) (so) Identificado(s)* 1. Time Scrum Identificado*

8.4 Desenvolver o(s) pico(s) 8.5 Criar o Backlog Priorizado do 8.6 Conduzir o Planejamento da
Produto Release

ENTRADAS ENTRADAS ENTRADAS


1. Time Central do Scrum* 1. Time Central do Scrum* 1. Time Central do Scrum*
2. Declarao da Viso do Projeto* 2. pico(s)* 2. Stakeholders*
FERRAMENTAS 3. Personas* 3. Declarao da Viso do Projeto*
1. Reunies dos Grupos de Usurios* FERRAMENTAS 4. Backlog Priorizado do Produto*
SADAS 1. Mtodos de Priorizao da Estria de 5. Critrio de Pronto*
1. pico(s)* Usurio* FERRAMENTAS
2. Personas* SADAS 1. Sesses do Planejamento da Release*
1. Backlog Priorizado do Produto* 2. Mtodos de Priorizao da Release*
2. Critrio de Pronto* SADAS
1. Cronograma de Planejamento da
Release*
2. Durao do Sprint*

Figura 8-2: A Viso Geral de Iniciar (Fundamentos)

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

136 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.1 Criar a Viso do Projeto


A figura 8-3 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Criar a Viso do
Projeto.

1. Caso de Negcio do Projeto* 1. Reunio da Viso do Projeto* 1. Dono do Produto Identificado*


2. Dono do Produto do Programa 2. Sesses JAD 2. Declarao da Viso do Projeto*
3. Scrum Master do Programa 3. Anlise SWOT 3. Termo de Abertura do Projeto
4. Anlise de Gap 4. Oramento do Projeto
4. Stakeholder(s) do Programa
5. Dono do Produto Chefe
6. Backlog do Produto do Programa
7. Julgamento do Projeto
8. Prova de Conceito
9. Viso da Empresa
8
10. Misso da Empresa
11. Estudo de Mercado
12. Recomendaes do Scrum
Guidance Body

Figura 8-3: Criar a Viso do ProjetoEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 137


8 INICIAR

Figura 8-4: Criar a Viso do ProjetoDiagrama de Fluxo de Dados

138 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.1.1 Entradas

8.1.1.1 Caso de Negcio do Projeto*

Um caso de negcio pode ser um documento bem estruturado, ou simplesmente uma declarao verbal
que expressa a razo para iniciar um projeto. Pode ser formal e abrangente, ou informal e breve.
Independentemente de seu formato, muitas vezes inclui informaes substanciais sobre o background do
projeto; a finalidade do negcio pretendido e os resultados desejados, uma anlise SWOT e um relatrio de
anlise de Gaps, uma lista de riscos identificados, e estimativas de tempo, esforo e custo.

O projeto comea com a apresentao do Caso de Negcio do Projeto. Um caso de negcio apresentado
aos stakeholders e patrocinadores. Os stakeholders compreendem os benefcios do negcio, esperados do
projeto, e os patrocinadores confirmam que iro fornecer os recursos financeiros para o projeto.

8.1.1.2 Dono do Produto do Programa


8
O Dono do Produto do Programa a pessoa responsvel por maximizar o valor do negcio para um
programa, por articular as necessidades do cliente e por manter a justificativa de negcio para o programa,
tambm podem fornecer inputs valiosos de como os projetos de um programa devem ser visionados. Alm
disso, o Dono do Produto do Programa gerencia o Backlog do Produto do Programa.

O Dono do Produto do Programa interage com o Dono do Produto do Portflio para garantir o alinhamento
do programa com as metas e objetivos do portflio. Tambm est envolvido na nomeao de Donos do
Produto para projetos individuais, e em garantir que a viso, objetivos, resultados e lanamentos dos
projetos individuais se alinham com os do programa.

8.1.1.3 Scrum Master do Programa

O Scrum Master do Programa um facilitador que garante que todos os times do projeto, no programa,
sejam favorecidos com um ambiente propcio a concluso do projeto com sucesso. O Scrum Master do
Programa guia, facilita, e ensina as prticas do Scrum, para todos os envolvidos no programa, fornece
diretrizes aos Scrum Masters de projetos individuais, remove os impedimentos encontrados pelos diferentes
times do projeto, coordena com o Scrum Guidance Body, a definio de objetivos relacionados com a
qualidade, regulamentaes governamentais, de segurana e outros parmetros-chave da organizao, e,
assegura que os processos do Scrum sejam seguidos durante o programa.

O Scrum Master do Programa interage com o Scrum Master do Portflio para garantir o alinhamento do
programa com as metas e objetivos do portflio. Tambm est envolvido na nomeao de Scrum Masters
para projetos individuais, e em garantir que a viso, objetivos, resultados e lanamentos dos projetos
individuais se alinham com os do programa.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 139


8 INICIAR

8.1.1.4 Stakeholder(s) do Programa

um termo coletivo que inclui os clientes, usurios e patrocinadores (para um programa), que influenciam
todos os projetos do programa, ao longo do desenvolvimento do projeto. Os Stakeholders do Programa
tambm podem ajudar a definir a viso do projeto e a fornecer orientao sobre o valor do negcio.

Os Stakeholders do Programa interagem com os Stakeholders do Portflio para garantir o alinhamento do


programa com as metas e objetivos do portflio. Tambm esto envolvidos na nomeao de Stakeholders
para projetos individuais, e em garantir que a viso, objetivos, resultados e lanamentos dos projetos
individuais se alinham com os do programa.

8.1.1.5 Dono do Produto Chefe

No caso de grandes projetos com inmeros Times Scrum, ter um Dono do Produto Chefe pode ser uma
necessidade. Este papel responsvel por coordenar o trabalho de vrios Donos do Produto. O Dono do
Produto Chefe prepara e mantm o Backlog Priorizado do Produto completo para o projeto, coordenando o
trabalho entre os Donos do Produto dos Times Scrum. Os Donos do Produto, por sua vez, gerenciam suas
respectivas partes no Backlog Priorizado do Produto.

O Dono do Produto Chefe tambm interage com o Dono do Produto do Programa para garantir o
alinhamento de grandes projetos, com as metas e objetivos do programa.

8.1.1.6 Backlog do Produto do Programa

O Dono do Produto do Programa desenvolve o Backlog do Produto do Programa, que contm uma lista de
prioridades de negcios e de requisitos do projeto de alto nvel, preferencialmente escrito, sob a forma de
grandes Itens do Backlog do Programa. Estes so posteriormente refinados pelos Donos do Produto de
projetos individuais, quando eles criam e priorizam os Backlogs do Produto para os seus projetos. Estes
Backlogs Priorizados do Produto tm Estrias de Usurio menores, porm, detalhadas, que podem ser
aprovadas, estimadas, e comprometidas por Times Scrum individuais.

O Backlog do Produto do Programa continuamente refinado pelo Dono do Produto do Programa, para
garantir que os novos requisitos de negcios sejam adicionados, e que os requisitos j existentes estejam
devidamente documentados e priorizados. Isto assegura que os requisitos mais importantes no
cumprimento dos objetivos do programa, sejam classificados com alta prioridade, e que os restantes
recebam uma prioridade menor.

O Backlog do Produto do Programa criado para o programa, apresenta uma imagem maior de todos os
projetos que fazem parte do programa. Portanto, ele pode fornecer orientao significativa em relao as
metas, o escopo, os objetivos e os benefcios de negcio esperados do projeto.

140 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.1.1.7 Teste do Projeto

Se possvel, uma pequena demonstrao de escala ou um teste do projeto pode ser executado, como uma
experincia para prever e avaliar a viabilidade, tempo e custo, riscos, e possveis efeitos do projeto real.
Isso ajuda a avaliar o ambiente prtico e orienta o design do projeto real, antes do incio do projeto em uma
escala completa.

8.1.1.8 Prova de Conceito

A Prova de Conceito demonstra e comprova que a ideia por trs do projeto atual potencialmente vivel no
ambiente do mundo real. Muitas vezes, na forma de um prottipo, projetado para determinar a viabilidade
tcnica e financeira, ajudar a entender os requisitos e auxiliar na avaliao de decises de design, no incio
do processo. No entanto, a Prova de Conceito no precisa representar necessariamente os Entregveis do
projeto real.

8
8.1.1.9 Viso da Empresa

Compreender a Viso da Empresa ajuda o projeto a manter seu foco em objetivos da organizao e no
potencial futuro da empresa. O Dono do Produto pode utilizar as informaes da Viso da Empresa para
criar a Declarao da Viso do Projeto.

8.1.1.10 Misso da Empresa

A Misso da Empresa fornece um framework para a formulao das estratgias da empresa, e em geral
orienta a tomada de deciso. A Viso do Projeto deve ser enquadrada de tal forma, que o seu cumprimento
ajuda a organizao a cumprir sua misso.

8.1.1.11 Estudo de Mercado

O Estudo de Mercado refere-se pesquisa, coleta, comparao e anlise organizada de dados,


relacionados com as preferncias dos clientes para com os produtos. Muitas vezes, inclui dados extensos
sobre as tendncias de mercado, segmentao de mercado e processos de marketing. O estudo de
mercado tambm pode incluir um estudo analtico dos concorrentes, o que fornece uma melhor
compreenso dos pontos fortes e fracos dos concorrentes, ajudando os tomadores de deciso a formular
melhor o posicionamento dos produtos.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 141


8 INICIAR

8.1.1.12 Recomendaes do Scrum Guidance Body

O Scrum Guidance Body (SGB) um papel opcional. Geralmente consiste de um conjunto de documentos
e/ou um grupo de especialistas que esto geralmente envolvidos na definio de objetivos relacionados
com a qualidade, regulamentaes governamentais, de segurana e outros parmetros-chave da
organizao. Estes objetivos orientam o trabalho realizado pelo Dono do Produto, Scrum Master e Time
Scrum. O Scrum Guidance Body tambm ajuda a capturar as melhores prticas que devem ser usadas na
organizao, em todos os projetos Scrum.

O Scrum Guidance Body no toma decises relacionadas ao projeto. Em vez disso, atua como uma
consultoria ou estrutura de orientao para todos os nveis de hierarquia da organizao do projeto; no
portflio, programa e projeto. Os Times Scrum tem a opo de pedir conselho ao Scrum Guidance Body,
conforme exigido.

importante garantir que a viso do projeto se alinha com as recomendaes fornecidas pelo Scrum
Guidance Body e que o processo cumpre com todos padres e diretrizes estabelecidos pelo rgo.

8.1.2 Ferramentas

8.1.2.1 Reunio da Viso do Projeto*

Uma reunio com o(s) Stakeholder(s) do Programa, Dono do Produto do Programa, Scrum Master do
Programa e com o Dono do Produto Chefe. Esta reunio ajuda a identificar o contexto do negcio, os
requisitos do negcio e as expectativas dos stakeholders, a fim de desenvolver uma Declarao da Viso
do Projeto eficaz. O Scrum acredita em envolvimento e em colaborao estreita com todos os
representantes das empresas para obter seu buy-in para o projeto, e para oferecer um valor maior.

8.1.2.2 Sesses de JAD

Uma sesso de Joint Application Design (JAD) uma tcnica de coleta de requisitos. um workshop
facilitador altamente estruturado que acelera o processo de Criar a Viso do Projeto, uma vez que permite
aos Stakeholders, e outros tomadores de decises, que cheguem a um consenso sobre o escopo, objetivo
e outras especificaes do projeto.

Consiste em mtodos para aumentar a participao do usurio, acelerando o desenvolvimento e


melhorando as especificaes. Os Stakeholder(s) Relevantes do Programa, Dono do Produto do Programa,
Scrum Master do Programa e o Dono do Produto do Programa, podem reunir-se para traar e analisar os
resultados desejados do negcio e visualizar a sua viso para o projeto Scrum.

142 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.1.2.3 Anlise SWOT

A Anlise SWOT uma abordagem estruturada para o planejamento do projeto que ajuda a avaliar os
pontos fortes e fracos, as oportunidades e as ameaas relacionadas a um projeto. Este tipo de anlise
ajuda a identificar os fatores internos e externos que possam afetar o projeto. Os pontos fortes e fracos so
os fatores internos, enquanto que as oportunidades e ameaas so os fatores externos. A identificao
desses fatores ajuda os stakeholders e os tomadores de deciso a finalizar os processos, ferramentas e
tcnicas a serem utilizadas para atingir os objetivos do projeto. A realizao de uma anlise SWOT permite
a identificao precoce de prioridades, de mudanas potenciais e de riscos.

8.1.2.4 Anlise de Gap

A Anlise de Gap uma tcnica usada para comparar o estado atual, real, com o estado desejado. Em
uma organizao, isto envolve a determinao e a documentao da diferena entre a capacidade de
negcio atual e o conjunto final de capacidades desejado. Um projeto normalmente iniciado para trazer
uma organizao para o estado desejado, por isso, a realizao de uma anlise de GAP pode ajudar os
tomadores de deciso a determinar a necessidade de um projeto. 8
As principais etapas envolvidas na Anlise de Gap so apresentadas na Figura 8-5.

Processos existentes
Capacidades existentes do Negcio
Processos para obter o resultado
Identificar desejado
Capacidades de Aspirao do Negcio
O gap

Os meios para resolver o gap


Desenvolver Priorizar capacidades para preencher o
gap

Figura 8-5: O Processo de Anlise de Gap

8.1.3 Sadas
8.1.3.1 O Dono do Produto Identificado*

A identificao do Dono do Produto uma das sadas deste processo. O Dono do Produto a pessoa
responsvel por maximizar o valor de negcio para o projeto. Sendo a pessoa responsvel por articular as
necessidades dos clientes e manter a justificativa de negcio para o projeto. O Dono do Produto representa
a Voz do Cliente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 143


8 INICIAR

Cada Time Scrum ter um Dono do Produto designado. Um projeto pequeno poder ter apenas um Dono
do Produto, enquanto que projetos maiores podero ter vrios. Estes Donos do Produto so responsveis
pelo gerenciamento de suas sees do Backlog Priorizado do Produto. Tambm escrevem as Estrias de
Usurio e gerenciam o refinamento do Backlog Priorizado do Produto.

O papel de Dono do Produto descrito com mais detalhes na seo 3.4.

8.1.3.2 Declarao da Viso do Projeto*

A Declarao da Viso do Projeto bem estruturada o resultado principal do processo de Criar a Viso do
Projeto. Uma boa Viso do Projeto explica as necessidades do negcio e o que o projeto se destina a
atender, ao invs de explicar como ele vai atender estas necessidades.

A Declarao da Viso do Projeto no deve ser muito especfica e deve ter espao para a flexibilidade.
possvel que o entendimento atual do projeto possa ser baseado em suposies que iro mudar no decorrer
do projeto, por isso importante que a viso do projeto seja flexvel o suficiente para acomodar essas
mudanas. A viso do projeto deve se concentrar no problema e no na soluo.

Exemplo:

VMFoods, uma rede de supermercados off-line, quer expandir com um portal de e-commerce on-line, e
entrou em contato com a sua empresa para criar o produto.

Viso do Projeto: Desenvolver um canal de vendas on-line para VMFoods fcil de usar e esteticamente
agradvel.

8.1.3.3 Termo de Abertura do Projeto

O Termo de Abertura do Projeto uma declarao oficial dos objetivos e resultados desejados em um
projeto. Em muitas organizaes, o Termo de Abertura do Projeto o documento oficial que formalmente
autoriza o incio projeto. Fornecendo ao time uma autorizao por escrito para comear os trabalhos do
projeto.

8.1.3.4 Oramento do Projeto

O Oramento do Projeto um documento financeiro que inclui os custos de pessoas, materiais e outras
despesas relacionadas em um projeto. O Oramento do Projeto normalmente assinado pelo(s)
patrocinador(es) para garantir que existem fundos suficientes. Uma vez assinado, o Dono do Produto e o
Scrum Master estaro envolvidos no gerenciamento do Oramento do Projeto de forma regular, e tambm
em garantir a disponibilidade de pessoal e de outros recursos necessrios para as atividades do projeto.

144 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.2 Identificar o Scrum Master e o(s) Stakeholder(s)


A figura 8-6 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Identificar o Scrum
Master e o(s) Stakeholder(s).

1. Dono do Produto* 1. Critrios de Seleo* 1. Scrum Master Identificado*


2. Declarao da Viso do Projeto* 2. Conselho de Especialista do RH 2. Stakeholder(s) (so)
3. Dono do Produto do Programa 3. Treinamento e Custos de Identificado(s)*
Treinamento
4. Scrum Master do Programa
4. Custos de Recurso
5. Dono do Produto Chefe
6. Scrum Master Chefe
7. Stakeholder(s) do Programa
8. Requisito de Pessoal
8
9. Comprometimento e
Disponibilidade de Pessoal
10. Matriz de Recurso Organizacional
11. Matriz de Requisito de
Habilidades
12. Recomendaes do Scrum
Guidance Body

Figura 8-6: Identificar o Scrum Master e o(s) Stakeholder(s)Entradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 145


8 INICIAR

Figura 8-7: Identificar o Scrum Master e o(s) Stakeholder(s)Diagrama de Fluxo de Dados

146 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.2.1 Entradas

8.2.1.1 Dono do Produto*

Descrito na seo 8.1.3.1.

8.2.1.2 Declarao da Viso do Projeto*

Descrito na seo 8.1.3.2.

8.2.1.3 Dono do Produto do Programa

Descrito na seo 8.1.1.2.

8
8.2.1.4 Scrum Master do Programa

Descrito na seo 8.1.1.3.

8.2.1.5 Dono do Produto Chefe

Descrito na seo 8.1.1.5.

8.2.1.6 Scrum Master Chefe

Os Grandes projetos requerem que mltiplos Times Scrum trabalharem em paralelo. As informaes
coletadas por um time podem ter que ser devidamente comunicadas aos outros times. O Scrum Master
Chefe responsvel por esta atividade.

A Coordenao entre os vrios Times Scrum que trabalham em um projeto, geralmente feita atravs da
Reunio do Scrum de Scrums (SOS) (ver seo 3.7.2.1). Sendo similar Reunio Diria e, sendo facilitada
pelo Scrum Master Chefe. O Scrum Master Chefe tipicamente o indivduo responsvel por abordar os
impedimentos que impactam mais de um time Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 147


8 INICIAR

8.2.1.7 Stakeholder(s) do Programa

Descrito na seo 8.1.1.4.

8.2.1.8 Requisito de Pessoas

A Identificao de Requisito de Pessoas um dos passos iniciais na seleo do Scrum Master e do(s)
Stakeholder(s). importante documentar os papis e as responsabilidades de todos aqueles que vo estar
envolvidos na realizao das tarefas no projeto. Isso inclui todos os indivduos envolvidos no projeto, com
qualquer ttulo, independentemente se seu papel central ou no-essencial.

Normalmente, o Dono do Produto ou o Scrum Master trabalha diretamente com o Departamento de


Recursos Humanos da empresa para determinar e finalizar os Requisitos de Pessoas para um projeto.

8.2.1.9 Comprometimento e Disponibilidade de Pessoas

Antes de selecionar o Scrum Master e o(s) Stakeholder(s), a disponibilidade dos mesmos deve ser
confirmada. Somente os membros do time que estaro disponveis e que podero se comprometer
totalmente ao projeto, devem ser selecionados. A Disponibilidade e o Comprometimento das pessoas so
comumente retratados na forma de calendrios, mostrando quando os recursos humanos estaro
disponveis para trabalhar, durante toda a durao do projeto.

Para ser eficaz, Times Scrum devem, idealmente, ter de seis a dez membros; e substituir ou alterar os
membros do time no aconselhvel em Times Centrais do Scrum. Assim, importante ter pessoas no
Time Central do Scrum, que esto disponveis e totalmente comprometidas com o projeto.

8.2.1.10 Matriz de Recurso Organizacional

A Matriz de Recurso Organizacional uma representao hierrquica entre a combinao de uma estrutura
organizacional funcional e de uma estrutura organizacional projetizada. As organizaes matriciais renem
os membros de diferentes departamentos funcionais para um projeto, tais como: tecnologia da informao,
finanas, marketing, vendas, produo e outros departamentos, e criam times multifuncionais.

Os membros do time em uma organizao matricial cumprem dois objetivos: funcional e de projeto. Os
membros do time so dirigidos pelo(s) Dono(s) do Produto, com relao as atividades relacionadas ao
projeto, enquanto que os gerentes funcionais realizam atividades administrativas relacionadas aos seus
departamentos, tais como, avaliaes de desempenho e aprovaes de pedidos de frias.

148 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.2.1.11 Matriz de Requisito de Habilidades

A Matriz de Requisito de Habilidades, tambm conhecida como um quadro de competncias, utilizada


para avaliar as lacunas de habilidades e requisitos de treinamento para os membros do time. Essa matriz
mapeia as habilidades e capacidades, e o nvel de interesse dos membros do time, em utiliz-las em um
projeto. Utilizando essa matriz, a organizao pode avaliar as lacunas de competncias em membros do
time e identificar os colaboradores que necessitam de treinamento adicional em uma determinada rea ou
competncia.

8.2.1.12 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

8.2.2 Ferramentas
8
8.2.2.1 Critrios de Seleo*

A Seleo do(s) Scrum Master(s) apropriado(s) e a identificao do(s) Stakeholder(s) relevante(s) crucial
para o sucesso de qualquer projeto. Em alguns projetos, podem haver condies pr estipuladas contendo
os membros do time e as suas funes.

Quando existe flexibilidade na escolha do(s) Scrum Master(s), os seguintes Critrios de Seleo so
importantes:

1. Capacidade de resolver problemasEste um dos principais critrios a ser considerado ao se


selecionar o(s) Scrum Master(s). O(s) Scrum Master(s) deve ter as habilidades e experincia
necessrias para ajudar a remover todos os impedimentos para o Time Scrum.
2. DisponibilidadeO Scrum Master deve estar disponvel para programar, supervisionar e facilitar
vrias reunies, incluindo a Reunio de Planejamento da Release, Reunio Diria, entre outras
reunies relacionadas com o Sprint.
3. ComprometimentoO Scrum Master deve estar altamente comprometido em garantir que o Time
Scrum seja fornecido com um ambiente de trabalho propcio para garantir a entrega bem sucedida
de projetos Scrum.
4. Estilo de Liderana ServidoraPara mais detalhes, consulte a seo 3.10.4.1

Ao identificar o(s) Stakeholder(s), importante lembrar que os stakeholders so todos os clientes, usurios
e patrocinadores, que interagem frequentemente com o Dono do Produto, Scrum Master e Time Scrum
para fornecer inputs e para facilitar a criao de produtos do projeto. Os stakeholders influenciam o projeto
durante todo o seu ciclo de vida.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 149


8 INICIAR

8.2.2.2 Consellho de Especialistas do RH

Os Conselhos de Especialistas, gerentes da rea de Recursos Humanos, podem ser valiosos na


identificao do Scrum Master e do(s) Stakeholder(s). O departamento de RH possui conhecimento
especializado sobre os colaboradores de uma organizao e sobre vrias tcnicas que podem ajudar na
identificao do Scrum Master e do(s) Stakeholder(s).

8.2.2.3 Treinamento e Custos de Treinamento

O Scrum um framework radicalmente diferente dos mtodos tradicionais de gerenciamento de projetos.


Os membros do time s vezes no possuem o conhecimento ou as habilidades necessrias para trabalhar
no ambiente Scrum. O Dono do Produto deve avaliar as necessidades potenciais de treinamento entre os
membros do time e facilitar este treinamento para amenizar eventuais gaps de conhecimento no time. O
Dono do Produto normalmente responsvel por avaliar e selecionar os membros do time, mas muitas
vezes faz isso com o auxlio do Scrum Master, que poder ter um conhecimento adicional dos recursos por
ter trabalhado com eles em outros projetos.

O treinamento adequado deve ser fornecido aos membros do Time Scrum, tanto antes do incio do trabalho,
quanto durante a realizao do mesmo. Os membros do Time Scrum tambm devem estar prontos para
aprender uns com os outros, e com as pessoas mais experientes no time.

8.2.2.4 Custos de Recurso

Uma das principais consideraes na seleo de pessoas tem a ver com o equilbrio relacionado a
experincia versus salrio. Existem outros fatores relacionados a pessoas que impactam custos, e que s
vezes tambm precisaro ser considerados. Idealmente, o(s) Scrum Master(s), os membros do time e o(s)
stakeholder(s) devem estar no mesmo local de trabalho, para que eles possam se comunicar com
frequncia e com facilidade. Se isso no for possvel e existirem times distribudos, recursos adicionais
devero ser dedicados para facilitar a comunicao, para entender as diferenas culturais, para sincronizar
o trabalho, e para manter o compartilhamento de conhecimento.

150 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.2.3 Sadas

8.2.3.1 O Scrum Master Identificado*

O Scrum Master um facilitador e "lder servidor", que garante ao Time Scrum o fornecimento de um
ambiente propcio para concluir com sucesso o projeto. O Scrum Master guia, facilita e ensina as prticas
do Scrum para todos os envolvidos no projeto; remove os impedimentos encontrados pelo time; e, assegura
que os processos do Scrum estejam sendo seguidos. O Dono do Produto responsvel pela identificao
do Scrum Master para um projeto do Scrum.

O papel de Scrum Master descrito com mais detalhes na seo 3.4.

8.2.3.2 Stakeholder(s) (so) Identificado(s)*

Stakeholder(s), um termo coletivo que inclui clientes, usurios e patrocinadores, que muitas vezes
interagem com o Time Central de Scrum e que influenciam o projeto durante o processo de 8
desenvolvimento do produto. para os stakeholders que o projeto produz os benefcios colaborativos.

O(s) papel(is) de Stakeholder(s) (so) descrito(s) na seo 3.3.2.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 151


8 INICIAR

8.3 Formar o Time Scrum


A figura 8-8 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Formar o Time
Scrum.

1. Dono do Produto* 1. Seleodo Time Scrum* 1. Time Scrum Identificado*


2. Scrum Master* 2. Conselho de Especialista do RH 2. Pessoa para Backup
3. Declarao da Viso do Projeto * 3. Custo de Pessoal 3. Plano de Colaborao
4. Dono do Produto Chefe 4. Trainamento e Custos de 4. Plano de Team Building
5. Requisito de Pessoal Treinamento
6. Comprometimento e 5. Custos de Recurso
Disponibilidade de Pessoal
7. Matriz de Recurso Organizacional
8. Matriz de Requisito de
Habilidades
9. Requisito de Recursos
10. Recomendaes do Scrum
Guidance Body

Figura 8-8: Formar o Time ScrumEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

152 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

Figura 8-9: Formar o Time ScrumDiagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 153


8 INICIAR

8.3.1 Entradas

8.3.1.1 Dono do Produto*

Descrito na seo 8.1.3.1.

8.3.1.2 Scrum Master*

Descrito na seo 8.2.3.1.

8.3.1.3 Declarao da Viso do Projeto*

Descrito na seo 8.1.3.2.

8.3.1.4 Dono do Produto Chefe

Descrito na seo 8.1.1.5.

8.3.1.5 Requisito de Pessoal

Descrito na seo 8.2.1.8.

8.3.1.6 Comprometimento e Disponibilidade de Pessoal

Descrito na seo 8.2.1.9.

8.3.1.7 Matriz de Recurso Organizacional

Descrito na seo 8.2.1.10.

8.3.1.8 Matriz de Requisito de Habilidades

Descrito na seo 8.2.1.11.

154 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.3.1.9 Requisito de Recursos

Esses requisitos incluem todos os recursos (exceto recursos de pessoal), necessrios para o
funcionamento eficaz do Time Scrum. Esses recursos incluem a infra-estrutura de escritrio, o espao para
reunies, os equipamentos de trabalho, Scrumboards, etc. No caso de times virtuais, outros recursos
adicionais devem ser considerados, tais como: as ferramentas de colaborao; videoconferncia, depsito
de documentos compartilhados, servios de traduo, etc.

8.3.1.10 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

8.3.2 Ferramentas

8.3.2.1 Seleo do Time Scrum* 8

O Time Scrum o centro de qualquer projeto Scrum, e importante obter no time os membros certos, para
a entrega bem sucedida de projetos Scrum. Os membros do Time Scrum so generalistas/especialistas, no
sentido de que possuem conhecimento em vrias reas, e so especialistas em pelo menos uma delas.
Alm de sua experincia, so as habilidades sociais dos membros do time que determinam o sucesso de
times auto-organizados.

Os membros ideias do Time Scrum so independentes, auto-motivados, focados no cliente, responsveis e


colaborativos. O time deve ser capaz de promover um ambiente de pensamento independente e de tomar
decises em grupo, a fim de extrair o mximo possvel de benefcios desta estrutura.

8.3.2.2 Conselho de Especialista do RH

Os Conselhos de Especialistas, de gerentes da rea de Recursos Humanos (RH), podem ser valiosos na
formao do Time Scrum. O departamento de RH possui conhecimento especializado sobre os
colaboradores de uma organizao, e sobre vrias tcnicas que podem ajudar os Donos do Produto, os
Scrum Masters e os patrocinadores a identificarem os membros certos para o time.

8.3.2.3 Custos de Pessoal

Todos os custos associados com os requisitos de pessoal precisam ser avaliados, analisados, aprovados e
orados.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 155


8 INICIAR

8.3.2.4 Treinamento e Custos de Treinamento

Os membros do time podem no possuir as habilidades e conhecimentos necessrios para realizar as


tarefas especializadas. O Dono do Produto deve avaliar as necessidades potenciais de treinamento dos
membros do time, e fornec-lo, quando qualquer gap de habilidade ou de conhecimento for encontrado.

Para uma aplicao verdadeiramente eficaz do Scrum, deve se haver um nvel significativo de conscincia
no mbito da organizao sobre os princpios e valores do Scrum. Esta conscientizao ir auxiliar na
execuo bem sucedida do Scrum. O Time Scrum deve ser sensibilizado e treinado nas prticas do Scrum
e o Scrum Master deve desempenhar para o time o papel de um treinador. Pelo fato do planejamento de
Sprints ser um fator importante de sucesso, o treinamento ir ajudar os times a entenderem como discutir e
identificar metas alcanveis do Sprint. O Scrum Master precisa extrair o melhor do Time Scrum,
motivando-os e facilitando seu processo de desenvolvimento. Atravs do treinamento dos membros do
time, o Scrum Master pode ajud-los a articular os problemas e desafios que possam enfrentar.
Normalmente quaisquer problemas ou conflitos vividos dentro do time, so resolvidos pelo time, com
treinamento e assistncia do Scrum Master, conforme necessrio. O Scrum Master deve abordar questes
como, a baixa moral ou a falta de coordenao dentro do time, sendo responsvel pela remoo de
impedimentos para o time. Quando necessrio, o Scrum Master pode escalar problemas e impedimentos
externos, para a gerncia, buscando a resoluo ou remoo dos mesmos.

O Treinamento e os Custos do Treinamento tambm so discutidos no processo de Identificar o Scrum


Master e o(s) Stakeholder(s), seo 8.2.2.3.

8.3.2.5 Custos de Recurso

Os custos associados a todos os requisitos que no esto relacionados a pessoal, devem ser avaliados,
analisados, aprovados e orados. Um recurso no ambiente do projeto qualquer coisa utilizada para
executar uma tarefa ou atividade, incluindo, mas no limitando-se a: equipamento, material, servios de
terceiros, e espao fsico.

8.3.3 Sadas

8.3.3.1 O Time Scrum Identificado*

O Time Scrum um grupo ou um time de pessoas que so responsveis por entender os requisitos de
negcio especificados pelo Dono do Produto, estimar as Estrias de Usurio e criar os entregveis finais do
projeto. Os Times Scrum so multifuncionais e auto-organizados. O time decide a quantidade de trabalho a
que ir se comprometer em um Sprint e determina a melhor maneira de executar o trabalho. O Time Scrum
composto por membros dos times multifuncionais, que realizam todo o trabalho envolvido na criao de
Entregveis potencialmente utilizveis, incluindo o desenvolvimento, os testes, a garantia de qualidade, etc.

156 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

Identificar o Time Scrum uma responsabilidade do Dono do Produto, muitas vezes, ocorre com o auxlio
do Scrum Master.

O papel do Time Scrum descrito em mais detalhe na seo 3.6.

8.3.3.2 Pessoal para Backup

Ao selecionar os times, outro aspecto importante a criao de backups para cada membro do Time
Scrum. Embora a disponibilidade e o comprometimento dos membros do time estejam confirmados com
antecedncia, problemas podem surgir; como uma doena, emergncia familiar, ou um membro do time
deixando a organizao. Os Times Scrum trabalham em pequenos grupos de seis a dez pessoas. Tendo
Pessoal para Backup garante que no ocorrer um grande impacto na produtividade, devido perda de um
membro do time.

8.3.3.3 Plano de Colaborao


8
A colaborao um elemento muito importante em Scrum. O planejamento de como os vrios tomadores
de deciso, stakeholders, e membros do time devem se envolver e colaborar uns com os outros vital. O
Plano de Colaborao uma sada opcional, que pode ser formal ou informal. s vezes, pode
simplesmente ser um acordo verbal entre os stakeholders, j que o Scrum evita qualquer documentao
desnecessria. No entanto, para projetos maiores e mais complexos, especialmente aqueles com times
distribudos, um acordo mais formal pode precisar ser colocado em prtica. O plano pode abordar como os
membros do Time Central do Scrum, Stakeholder(s), entre outras pessoas envolvidas no projeto Scrum,
iro se comunicar e colaborar durante todo o projeto, e tambm podem definir as ferramentas ou tcnicas
especficas a serem utilizadas para essa finalidade. Por exemplo, em times distribudos, pode existir a
necessidade de um acordo sobre, quando e como as reunies sero realizadas, que tipo de ferramentas de
comunicao sero utilizadas, e quem dever estar envolvido em cada tipo de reunio.

8.3.3.4 Plano de Team Building

Considerando que um Time Scrum multifuncional, cada membro precisa participar ativamente de todos os
aspectos do projeto. O Scrum Master deve identificar problemas potenciais que possam surgir com os
membros do time, e tentar resolv-los de forma diligente utilizando o Plano de Team Building, a fim de
manter um time eficaz.

Para construir a coeso do time, o Scrum Master deve garantir que as relaes entre os membros do time
sejam positivas e que os membros do time estejam unidos na realizao das metas gerais do projeto e da
organizao, levando assim a uma maior eficincia e produtividade.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 157


8 INICIAR

Neste contexto, importante o estudo da seo 3.10, que discute as teorias populares de RH e as suas
relevncias em Scrum.

8.4 Desenvolver o(s) pico(s)


A figura 8-10 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Desenvolver
pico(s).

1. Time Central do Scrum* 1. Reunies dos Grupos de 1. pico(s)*


2. Declarao da Viso do Projeto* Usurios* 2. Personas*
3. Stakeholder(s)
2. Workshops da Estria de 3. Mudanas Aprovadas
4. Backlog do Produto do Programa
5. Solicitaes de Mudana Usurio 4. Riscos Identificados
Aprovadas 3. Reunies do Grupo de Foco
6. Solicitaes de Mudana No 4. Entrevistas com o Usurio ou
Aprovadas Cliente
7. Riscos de Programa e de Portflio 5. Questionrios
8. Leis e Regulamentos 6. Tcnicas de Identificao de
9. Contratos Aplicveis Riscos
10. Informaes sobre o Projeto 7. Expertise do Scrum Guidance
Anterior Body
11. Recomendaes do Scrum
Guidance Body

Figura 8-10: Desenvolvimento de picosEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

158 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

Figura 8-11: Desenvolvimento de picosDiagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 159


8 INICIAR

8.4.1 Entradas

8.4.1.1 Time Central do Scrum*

O Time Central do Scrum constitudo pelo Time Scrum, Scrum Master e Dono do Produto, conforme
descrito na seo 3.3.1.

8.4.1.2 Declarao da Viso do Projeto*

Descrito na seo 8.1.3.2.

8.4.1.3 Stakeholder(s)

Descrito na seo 8.2.3.2.

8.4.1.4 Backlog do Produto do Programa

Descrito na seo 8.1.1.6.

8.4.1.5 Solicitaes de Mudana Aprovadas

As Solicitaes de Mudana Aprovadas provenientes do programa ou portflio, so entradas que devem ser
adicionadas lista de mudanas do projeto aprovadas, para implementao em Sprints futuros. Cada
mudana pode exigir o seu prprio pico ou Estria de Usurio, e poder se tornar uma entrada para o
processo de Desenvolver pico(s). As Solicitaes de Mudana Aprovadas deste processo tambm podem
ser resultado de outros processos do Scrum.

As Solicitaes de Mudana e as Solicitaes de Mudana Aprovadas so discutidas nas sees 6.3.1,


6.4.2.1 e 6.6.

8.4.1.6 Solicitaes de Mudana No Aprovadas

Os pedidos de mudanas so geralmente apresentados na forma de Solicitaes de Mudana. As mesmas


permanecem no aprovadas at que sejam formalmente aprovadas. As Solicitaes de Mudana No

160 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

Aprovadas para o processo de Desenvolver pico(s) podem ter origem nos processos de Criar os
Entregveis, Reunio Diria, entre outros.

As Solicitaes de Mudana e as Solicitaes de Mudana No Aprovadas so discutidas nas sees 6.3.1,


6.4.2.1 e 6.6.

8.4.1.7 Riscos de Programa e de Portflio

Os riscos relacionados a um portflio ou programa que tambm tero impacto sobre projetos que fazem
parte do respectivo portfolio ou programa. Durante a avaliao de riscos em portflios e programas, se for
determinado que um risco pode afetar um projeto individual, informaes relevantes ao risco devem ser
comunicadas ao Dono do Produto e ao Time Scrum. Os Riscos do Programa e do Portflio podem ser
entradas para o processo de Desenvolver pico(s) e podem ter um impacto geral na maneira como este
processo conduzido.

Os Riscos do Programa e do Portflio esto descritos na seo 7.5.1.


8

8.4.1.8 Leis e Regulamentos

Dependendo do projeto, podem haver Leis e Regulamentos impostos pelos rgos do governo, o que
impacta no planejamento e na execuo. As leis so externas organizao e impostas por uma entidade
governamental. Os regulamentos podem ser internos ou externos. Os internos so aqueles que so
aplicveis no mbito da empresa, normalmente com base em polticas. Estes regulamentos podem estar
relacionados ao sistema de gerenciamento de qualidade, regulamentos financeiros, regulamentos de
pessoal, etc. Os externos so aqueles relacionados aos padres estabelecidos pelo governo, normas e
requisitos.

As Leis e os Regulamentos devem ser considerados durante o desenvolvimento dos picos. Os picos so
baseados em requisitos de negcio. Para atender a esses requisitos, o time do projeto tem que respeitar
tanto as leis e regulamentos internos quanto externos.

s vezes, algumas das Leis e Regulamentos que afetam vrios projetos Scrum podem ser includos como
parte das Recomendaes do Scrum Guidance Body, conforme discutido na seo 8.1.1.12.

8.4.1.9 Contratos Aplicveis

Se o projeto inteiro ou partes dele esto sendo cumpridas por meio de um contrato, o contrato define o
escopo do trabalho e as condies especficas do contrato. O tipo de contrato utilizado influencia os risco
do projeto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 161


8 INICIAR

Alguns dos tipos mais comuns de contratos utilizados em projetos do Scrum so os seguintes:

Contrato de Entrega IncrementalEste contrato inclui pontos de inspees em intervalos regulares,


ajudando o cliente ou os stakeholders a tomarem decises sobre o desenvolvimento do produto
periodicamente ao longo do projeto, em cada ponto de inspeo. O cliente pode aceitar o desenvolvimento
do produto, optar por parar o seu desenvolvimento, ou solicitar modificaes.

Contrato Joint VentureEste contrato geralmente usado quando duas ou mais partes formam uma
parceiria para a realizao do trabalho de um projeto. Ambas as partes envolvidas no projeto recebero o
Retorno sobre Investimento porque os rendimentos ou benefcios gerados sero compartilhados entre as
partes.

Contrato de Desenvolvimento em FasesEsse contrato assegura a disponibilizao de fundos a cada


ms ou a cada trimestre, aps a concluso de uma release com xito. Incentiva tanto o cliente como o
fornecedor e garante que o risco monetrio do cliente seja limitado a esse determinado perodo de tempo,
j que os lanamentos fracassados no so financiados.

Contrato de Incentivo e PenalidadeEsse contrato baseia-se no acordo de que o fornecedor ser


recompensado com um incentivo financeiro, se os produtos do projeto forem entregues no tempo, mas
incorrer em sanes financeiras, se a entrega estiver atrasada.

Outros tipos de contrato populares incluem: o contrato de pagamento pelas caractersticas, o contrato de
tempo e de materiais, o contrato de preo fixo e escopo fixo, e o contrato de lucro fixo.

Os picos devem ser desenvolvidos de acordo com os termos e condies do tipo de contrato a ser
utilizado.

8.4.1.10 Informaes sobre o Projeto Anterior

As informaes e os conhecimentos adquiridos a partir de projetos anteriores, semelhantes e dentro da


organizao, so inputs valiosos para o desenvolvimento dos picos e para a avaliao do risco. As
Informaes sobre Projetos Anteriores podem incluir observaes de gerente de projetos, registros de
projeto e comentrios por parte dos stakeholders.

Algumas informaes e melhores prticas relacionadas com as informaes do projeto anterior podem estar
disponveis atravs das Recomendaes do Scrum Guidance Body.

8.4.1.11 Recomendaes do Scrum Guidance Body

Discutidas na seo 8.1.1.12

As Recomendaes do Scrum Guidance Body podem incluir informaes sobre as regras, regulamentos,
padres, e sobre as melhores prticas para o desenvolvimento de picos.

162 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.4.2 Ferramentas

8.4.2.1 Reunies do Grupo de Usurios*

As Reunies do Grupo de Usurios envolvem o(s) Stakeholder(s) relevante(s), principais usurios ou


clientes do produto. Eles fornecem ao Time Central do Scrum informaes de primeira mo sobre as
expectativas do usurio. Isso ajuda na formulao dos Critrios de Aceitao do produto e fornece
informaes valiosas para o desenvolvimento de picos. As Reunies do Grupo de Usurios so vitais na
preveno de retrabalho caro, que pode ser resultado pela falta de entendimento sobre as expectativas e
requisitos. Essas reunies tambm promovem o buy-in para o projeto e criam um entendimento comum
entre o Time Central do Scrum e o(s) Stakeholder(s) relevante(s).

8.4.2.2 Workshops da Estria de Usurio

Os Workshops da Estria de Usurio so realizados como parte do processo de Desenvolver pico(s). O


Scrum Master o facilitador dessas sesses. O Time Central do Scrum inteiro est envolvido e, por vezes, 8
desejvel incluir outros Stakeholders. Esses workshops ajudam o Dono do Produto a priorizar os
requisitos, e permite que o Time Central do Scrum tenha uma perspectiva compartilhada dos Critrios de
Aceitao. Garantindo que os picos e que as Estrias de Usurio descrevem a funcionalidade do ponto de
vista dos usurios, sendo fceis de entender, e podendo serem estimadas com segurana. Os Workshops
da Estria de Usurio so teis na compreenso das expectativas do usurio para com os resultados, e so
excelentes para a formao de times. Tambm facilitam a preparao para o planejamento do prximo
Sprint. Um Workshop da Estria de Usurio uma boa plataforma para discutir e esclarecer todos os
elementos de um produto e, muitas vezes para se aprofundar nos mnimos detalhes garantindo um
entendimento claro.

8.4.2.3 Reunies dos Grupos de Foco

Os Grupos de Foco renem indivduos em uma sesso orientada para apresentar suas opinies,
percepes ou avaliaes com relao a um produto, servio ou resultado desejado. Os membros dos
Grupos de Foco tm a liberdade de fazerem perguntas uns para os outros e para obter esclarecimentos
sobre temas ou conceitos especficos. Atravs de questionamentos, crticas construtivas, e feedback, os
Grupos de Foco contribuem para um produto de melhor qualidade e respectivamente para satisfazerem as
expectativas dos usurios. Nessas reunies, os membros do grupo de foco, por vezes, chegam a um
consenso em certas reas, enquanto que em outras reas as suas opinies podem ser diferentes. Onde os
membros do grupo tm opinies ou perspectivas diferentes, so feitos todos os esforos para que essas
diferenas sejam resolvidas, a fim de se chegar a um consenso.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 163


8 INICIAR

As sesses do grupo de foco podem ajudar os times a terem ideias inovadoras, a solucionar problemas e a
dar sugestes de melhoria. Essas reunies facilitam a averiguao, e geram ideias e feedback dos
potenciais usurios e dos desenvolvedores dos produtos. So geralmente realizadas para o planejamento,
avaliao ou melhoria de um produto ou servio. Insights obtidos a partir destas reunies tambm podem
ajudar a desenvolver picos e Estrias de Usurio. s vezes, as Reunies dos Grupos de Foco so
realizadas para resolver os problemas que possam surgir durante o desenvolvimento dos picos.

8.4.2.4 Entrevistas de Usurios ou Clientes

O envolvimento dos stakeholders, a incluso do patrocinador, de usurios e de clientes do produto, so


importantes para se adquirir o contexto necessrio e o insight requerido para o desenvolvimento dos
picos. O tempo de qualidade gasto nas entrevistas de usurios e de clientes, ir resultar na garantia de
que os requisitos dos picos se alinham aos da Viso geral do Projeto, oferecendo assim um valor maior.

Essas entrevistas ajudam a:

Identificar e compreender as necessidades e expectativas do stakeholder


Coletar opinies e fatos
Entender a perspectiva do stakeholder com relao ao produto final
Coletar o feedback sobre o produto iterado ou parcialmente desenvolvido

8.4.2.5 Questionrios

Uma maneira econmica de se obter uma viso estatstica quantitativa e qualitativa de um grande nmero
de usurios ou clientes, atravs da utilizao de pesquisas ou Questionrios. Um Questionrio um
instrumento de pesquisa que contm perguntas a serem feitas a um entrevistado, a fim de coletar
informaes sobre um problema ou assunto especfico. Os Questionrios podem ser auto-administrados ou
administrados por um entrevistador.

O design dos Questionrios deve ser exercido de maneira cautelosa, selecionando o pblico-alvo certo, e
determinando um mtodo apropriado de implantao da pesquisa, para evitar o erro e a direo oblqua.

Durante o desenvolvimento dos picos, o Dono do Produto ou o Scrum Master pode realizar uma pesquisa
para coletar informaes relevantes fornecidas pelos stakeholders ou pelo Time Scrum.

8.4.2.6 Tcnicas de Identificao de Riscos

Descrito na seo 7.4.1.1

164 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.4.2.7 Expertise do Scrum Guidance Body

Descrito na seo 3.3.2

Durante o desenvolvimento dos picos, a Expertise do Scrum Guidance Body pode ser relacionada s
regras e aos regulamentos documentados, ou padres e melhores prticas, para a criao de picos.
Tambm pode existir um time de especialistas no assunto, que podem ajudar o Dono do Produto a criar os
picos. Este time pode incluir Analistas de Negcios, Arquitetos, Desenvolvedores Snior, Especialistas do
Scrum, ou outras pessoas experientes. Este grupo de especialistas geralmente no faz parte do time que
vai trabalhar em um projeto especfico, pois tendem a se movimentar de um projeto para outro com os
clientes ou usurios, durante a "fase de venda" ou "fase zero".

8.4.3 Sadas

8.4.3.1 pico(s)*
8
Os picos so escritos nas fases iniciais do projeto, quando a maioria das Estrias de Usurio so
funcionalidades de alto nvel ou quando as descries de produtos e requisitos so amplamente definidas.
So Estrias de Usurio grandes e no refinadas no Backlog Priorizado do Produto.

Uma vez que os picos surgem no Backlog Priorizado do Produto, so ento, divididos em Estrias de
Usurio pequenas e mais detalhadas, para serem concludos em um prximo Sprint. Estas Estrias de
Usurio menores, so geralmente simples, curtas e, a implementao de funcionalidades ou blocos de
tarefas a serem concludas em um Sprint ocorrem facilmente.

8.4.3.2 Personas*

As Personas so personagens fictcios altamente detalhados, representantes da maioria dos usurios, bem
como outros stakeholders, que podem no usar diretamente o produto final. As Personas so criadas para
identificar as necessidades base do usurio-alvo. A criao de Personas especficas, pode ajudar o time a
entender melhor os usurios, suas necessidades e os seus objetivos. Com base em uma Persona, o Dono
do Produto pode efetivamente priorizar os recursos para criar o Backlog Priorizado do Produto.

Criando uma Persona: Isso envolve a atribuio de um nome fictcio, e de preferncia uma imagem para o
personagem. A Persona ir conter atributos altamente especficos, tais como: idade, sexo, educao,
ambiente, interesses e objetivos. Uma citao que ilustra os requisitos da Persona tambm pode ser
incluso. Segue abaixo um exemplo de uma Persona para um site de viagens.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 165


8 INICIAR

Exemplo:

A Vanessa tem 39 anos de idade e mora em So Francisco. Depois de ter uma carreira de sucesso como
advogada, ela est seguindo a sua paixo por viagens. Ela gosta de ter opes ao escolher servios de
transporte areo e hospedagem, para que ela possa escolher o melhor, e mais acessvel. Ela fica frustrada
com sites lentos e desordenados.

8.4.3.3 Mudana Aprovadas

As Solicitaes de Mudana No Aprovadas podero ser aprovadas pelo Dono do Produto durante o
processo Desenvolver o(s) pico(s), s vezes com sugestes fornecidas pelos stakeholders. Tais
mudanas so categorizadas como Mudanas Aprovadas e podero ser priorizadas e implementadas em
Sprints futuros.

As Solicitaes de Mudana e as Solicitaes de Mudana Aprovadas so discutidas nas sees 6.3.1,


6.4.2.1 e 6.6.

8.4.3.4 Riscos Identificados

Durante a criao dos picos, novos riscos podem ser identificados.Esses riscos formam uma sada
importante desta fase e contribuem para o desenvolvimento do Backlog Priorizado do Produto (tambm
referido como o Backlog do Produto do Risco Ajustado).

A Identificao de Risco descrita na seo 7.4.1.

166 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.5 Criar o Backlog Priorizado do Produto


A figura 8-12 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Criar o Backlog
Priorizado do Produto.

1. Time Central do Scrum* 1. Mtodos de Priorizao da 1. Backlog Priorizado do Produto*


2. pico(s)* Estria de Usurio* 2. Critrio de Pronto*
3. Personas* 2. Workshop de Estrias de
4. Stakeholder(s) Usurio
5. Declarao da Viso do Projeto 3. Planejamento ou Valor
6. Backlog do Produto do Programa 4. Tcnicas de Avaliao de Risco
7. Requisitos de Negcio 5. Estimativa do Valor do Projeto
8. Solicitaes de Mudana 6. Mtodos de Estimativa da 8
Aprovadas Estria de Usurio
9. Riscos Identificados 7. Expertise do Scrum Guidance
10. Contratos Aplicveis Body
11. Recomendaes do Scrum
Guidance Body

Figura 8-12: Criar o Backlog Priorizado do ProdutoEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 167


8 INICIAR

Figura 8-13: Criar o Backlog Priorizado do ProdutoDiagrama de Fluxo de Dados

168 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.5.1 Entradas

8.5.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

8.5.1.2 pico(s)*

Descrito na seo 8.4.3.1.

8.5.1.3 Personas*

Descrito na seo 8.4.3.2.

8
8.5.1.4 Stakeholder(s)

Descrito na seo 8.2.3.2.

8.5.1.5 Declarao da Viso do Projeto

Descrito na seo 8.1.3.2.

8.5.1.6 Backlog do Produto do Programa

Descrito na seo 8.1.1.6.

8.5.1.7 Requisitos de Negcio

A soma de todos os conhecimentos adquiridos atravs de vrias ferramentas, como: entrevistas com o
usurio ou cliente, Questionrios, Sesses JAD, Anlise de Gap, Anlise SWOT, e outras reunies, ajudam
a ter uma melhor perspectiva sobre os requisitos de negcio e a criar o Backlog Priorizado do Produto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 169


8 INICIAR

8.5.1.8 Solicitaes de Mudana Aprovadas

Descrito na seo 8.4.3.3.

8.5.1.9 Riscos Identificados

Descrito na seo 8.4.3.4.

8.5.1.10 Contratos Aplicveis

Descrito na seo 8.4.1.9.

8.5.1.11 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

Durante a criao do Backlog Priorizado do Produto, as Recomendaes do Scrum Guidance Body podem
incluir informaes sobre as regras, regulamentos, padres e melhores prticas, para o desenvolvimento do
Backlog Priorizado do Produto.

8.5.2 Ferramentas

8.5.2.1 Mtodos de Priorizao da Estria de Usurio*

Algumas tcnicas utilizadas para priorizar as Estrias de Usurio, ou os requisitos no Backlog Priorizado do
Produto, com base no valor de negcio, so apresentadas a seguir:
Esquema de Priorizao MoSCoWO seu nome deriva das primeiras letras das palavras Must
have (deve ter), Should have (deveria ter), Could have (poderia ter), e Wont have (no vai
ter). Este mtodo de priorizao geralmente mais eficaz do que o de Esquemas Simples. Os
rtulos esto em ordem de prioridade decrescente, com, "deve ter" sendo aquelas Estrias de
Usurio que sem as quais o produto no ter valor, e, "no ter" sendo aquelas Estrias de
Usurio que embora seria bom ter, sua incluso no necessria.

Comparao PareadaNesta tcnica, uma lista de todas as Estrias de Usurio no Backlog


Priorizado do Produto criada e em seguida, cada Estria de Usurio comparada
individualmente com as outras Estrias de Usurio da lista, um de cada vez. Cada vez que duas

170 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

Estrias de Usurio so comparadas, tomada uma deciso em relao a qual das duas mais
importante. Atravs deste processo, uma lista priorizada de Estrias de Usurio pode ser gerada.

Mtodo de Ponto-100 O Mtodo de Ponto-100 foi desenvolvido por Dean Leffingwell e Don
Widrig (2003). Trata-se de dar ao cliente 100 pontos que ele pode usar para votar nas Estrias de
Usurio que considerar mais importante. O objetivo dar mais peso s Estrias de Usurios que
tem prioridade maior quando comparada com as demais disponveis. Cada membro do grupo
atribui pontos as vrias Estrias de Usurios, dando mais pontos para aquelas que acreditam
serem mais importantes. Aps a concluso do processo de votao, a priorizao determinada
pelo clculo do total de pontos atribudos a cada Estria de Usurios.

Anlise de Kano

Descrito na seo 4.5.2

8.5.2.2 Workshops da Estria de Usurio 8


Descrito na seo 8.4.2.2.

8.5.2.3 Planejamento para Valor

Descrito na seo 4.5.2

8.5.2.4 Tcnicas de Avaliao de Risco

Descrito na seo 7.4.2.1.

8.5.2.5 Estimativa do Valor do Projeto

Descrito na seo 4.5.1.

8.5.2.6 Mtodos de Estimativa da Estria de Usurio

Todas as ferramentas utilizadas no processo de Aprovar, Estimar e Comprometer a Estria de Usurio


(conforme descrito na seo 9.2.2) podem ser utilizadas para a criao de estimativas de alto nvel para
o(s) pico(s) quando o Backlog Priorizado do Produto criado. Algumas ferramentas so importantes:

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 171


8 INICIAR

1. Reunies dos Grupos de Usurios


2. Planejamento Poker
3. Fist of Five
4. Pontos de Estimativa de Custos
5. Outras Tcnicas de Estimativa

8.5.2.7 Expertise do Scrum Guidance Body

Descrito na seo 8.4.2.7

Durante a criao do Backlog Priorizado do Produto a Expertise do Scrum Guidance Body pode ser
relacionada s regras e aos regulamentos documentados, ou padres e melhores prticas, para a criao
dos picos. Tambm pode existir um time de especialistas no assunto, que podem ajudar o Dono do
Produto no processo de Criar o Backlog Priorizado do Produto. Este time pode incluir Analistas de
Negcios, Arquitetos, Desenvolvedores Snior, Especialistas do Scrum, ou outras pessoas experientes.
Este grupo de especialistas geralmente no faz parte do time que vai trabalhar em um projeto especfico,
pois tendem a mover-se de um projeto para outro com os clientes ou usurios, durante a "fase de venda" ou
"fase zero".

8.5.3 Sadas

8.5.3.1 Backlog Priorizado do Produto*

O Dono do Produto desenvolve um Backlog Priorizado do Produto, que contm uma lista de prioridades de
negcios e de requisitos dos projetos, escritos na forma de pico(s), que so as Estria de Usurio de alto
nvel. O Backlog Priorizado do Produto baseado em trs fatores principais: valor, risco ou incerteza, e
dependncias. Tambm pode ser referido como o Backlog do Produto de Risco Refinado, j que inclui os
riscos identificados e avaliados, relacionados ao projeto. Tambm engloba todas as Mudanas Aprovadas
que podem ser devidamente priorizadas no Backlog Priorizado do Produto (conforme descrito na seo
6.3.1).

ValorO Dono do Produto o responsvel por garantir a entrega dos produtos que fornecem em
primeiro lugar, o nvel mais alto de valor de negcio. Mesmo um produto extremamente valioso
pode no fazer parte da primeira release, se houverem outros produtos de maior valor que sejam
suficientes para a primeira release.

Risco e Incerteza Quanto maior a incerteza, mais arriscado ser o projeto. Portanto,
importante que os produtos de maior risco sejam classificados como de alta prioridade no Backlog
Priorizado do Produto. Os produtos com um nvel maior de risco tambm exigiro aes de
mitigao de risco. Quando essas aes de mitigao de riscos so priorizadas no backlog, o

172 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

resultado o Backlog do Produto de Risco Ajustado. O ajuste dos riscos no incio do projeto no
garante que o mesmo ser bem sucedido, porm, aumenta o nvel de conhecimento do time com
relao ao risco. Descrito na seo 7.4.3.

DependnciasGeralmente no possvel criar um Backlog Priorizado do Produto onde no


existam dependncias entre as Estrias de Usurio. Os requisitos funcionais muitas vezes
dependem de outros requisitos funcionais e at mesmo no-funcionais. Essas dependncias
podem afetar o modo como as Estrias de Usurio so priorizadas no Backlog Priorizado do
Produto. Duas das formas mais comuns para solucionar as dependncias so: a diviso de uma
nica estria em vrias partes ou a combinao de estrias interdependentes.

Estimativa As estimativas de alto nvel para o(s) pico(s), tambm esto disponveis no Backlog
Priorizado do Produto.

8.5.3.2 Critrios de Pronto*


8
Os Critrios de Pronto so um conjunto de regras aplicveis a todas as Estrias de Usurio. muito
importante ter uma definio clara de Pronto, porque esta, remove a ambiguidade dos requisitos e ajuda o
time a aderir s normas obrigatrias de qualidade. Esta definio clara usada para criar os Critrios de
Pronto que so uma sada do processo de Criar o Backlog Priorizado do Produto. Uma Estria de Usurio
considerada Pronta, aps ser demonstrada e aprovada pelo Dono do Produto, que a julga com base nos
Critrios de Pronto e nos Critrios de Aceitao da Estria de Usurio.

Exemplo dos Critrios de Pronto:

Projeto: A projeo de novas variantes de um carro esporte, popular, na LRA Ltda.

Critrios de Pronto:

O design aprovado pelo setor de Excelncia Tcnica.


O prottipo passa por todos os testes mandatrios do setor de Aerodinmica.
O design liberado para produo pelo setor de Propriedade Intelectual.
As expectativas de segurana do design so confirmadas atravs do relatrio do Setor de
Segurana do Design.
O relatrio de Estimativa de Custos aprovado para o design pelo Setor Financeiro.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 173


8 INICIAR

8.6 Conduzir o Planejamento da Release


A figura 8-14 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Conduzir o
Planejamento da Release.

1. Time Central do Scrum* 1. Sesses do Planejamento da 1. Cronograma de Planejamento


2. Stakeholder(s)* Release* da Release*
3. Declarao da Viso do Projeto* 2. Mtodos de Priorizao da 2. Durao do Sprint*
4. Backlog Priorizado do Produto* Release* 3. Clientes-alvo para a Release
5. Critrio de Pronto* 4. Backlog do Produto Priorizado
6. Dono do Produto do Programa e Refinado
7. Scrum Master do Programa
8. Dono do Produto Chefe
9. Backlog do Produto do
Programa
10. Requisitos de Negcio
11. Calendrio de Feriados
12. Recomendaes do Scrum
Guidance Body

Figura 8-14: Conduzir o Planejamento de ReleaseEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

174 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

Figura 8-15: Conduzir o Planejamento de ReleaseDiagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 175


8 INICIAR

8.6.1 Entradas

8.6.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

8.6.1.2 Stakeholder(s)*

Descrito na seo 8.2.3.2.

8.6.1.3 Declarao da Viso do Projeto*

Descrito na seo 8.1.3.2.

8.6.1.4 Backlog Priorizado do Produto*

Descrito na seo 8.5.3.1.

8.6.1.5 Critrios de Pronto*

Descrito na seo 8.5.3.2.

8.6.1.6 Dono do Produto do Programa

Descrito na seo 8.1.1.2.

8.6.1.7 Scrum Masterdo Programa

Descrito na seo 8.1.1.3.

8.6.1.8 Dono do Produto Chefe

Descrito na seo 8.1.1.5.

176 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

8.6.1.9 Backlog do Produto do Programa

Descrito na seo 8.1.1.6.

8.6.1.10 Requisitos de Negcio

Descrito na seo 8.5.1.7.

8.6.1.11 Calendrio de Frias

importante para o Time Scrum, manter o controle das datas em que todos os membros do time estaro
disponveis. Isto pode ser feito atravs do uso de um calendrio compartilhado que fornea as informaes
sobre os feriados oficiais, frias, planos de viagem, eventos, etc. Este calendrio vai ajudar o time no
planejamento e execuo dos Sprints.

8
8.6.1.12 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12

No processo de Conduzir o Planejamento da Release, as Recomendaes do Scrum Guidance Body


podem se relacionar com as regras, regulamentos, padres e melhores prticas para desenvolver o Plano
da Release. O Guidance Body pode ser a melhor autoridade para definir as diretrizes relacionadas ao valor
de negcio, as expectativas da release, as estratgias de implantao, a qualidade e a segurana.

8.6.2 Ferramentas

8.6.2.1 Sesses de Planejamento da Release*

As Sesses de Planejamento da Release so conduzidas para desenvolver um Plano da Release. O plano


define quando os vrios conjuntos de funcionalidades ou de produtos utilizveis sero entregues ao cliente.
Em Scrum, o principal objetivo das Sesses de Planejamento da Release criar um cronograma de plano
da release, e permitir que o Time Scrum tenha uma viso geral do cronograma da release e entrega, para o
produto que esto desenvolvendo, para que possam ento ajustar-se de acordo com as expectativas do
Dono do Produto e dos stakeholders relevantes (principalmente do patrocinador do projeto).

Muitas organizaes tm uma estratgia com relao ao lanamento de produtos. Algumas organizaes
preferem implantao contnua, onde uma release ocorre aps a criao de uma funcionalidade utilizvel

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 177


8 INICIAR

especfica. Outras organizaes preferem a implantao por fases, onde as releases ocorrem em intervalos
pr-definidos. Dependendo da estratgia da organizao, as Sesses de Planejamento da Release em
projetos podem ser motivadas pela funcionalidade (tendo como objetivo, a entrega da realease aps o
desenvolvimento de um conjunto pr-determinado de funcionalidade), ou pela data (onde a release ocorre
em uma data pr-definida).

J que o framework Scrum promove a informao baseada e a tomada de deciso iterativa, ao invs de
planejamento inicial detalhado (o que geralmente ocorre durante a prtica do mtodo tradicional de
gerenciamento de projeto), as Sesses de Planejamento da Release no precisam elaborar um Plano da
Release detalhado para todo o projeto. O Plano de Realease pode ser atualizado continuamente, conforme
a disponibilizao de informao relevante.

8.6.2.2 Mtodos de Priorizao da Release*

Os Mtodos de Priorizao da Release so usados para desenvolver um plano da release. Esses mtodos
so especficos da indstria e da organizao e geralmente so determinados pela alta administrao de
uma organizao.

8.6.3 Sadas

8.6.3.1 Cronograma de Planejamento da Release*

Um Cronograma de Planejamento da Release um dos principais resultados do processo de Conduzir o


Planejamento da Release. Um Cronograma de Planejamento da Release afirma quais entregveis devem
ser liberados para os clientes, juntamente com os intervalos planejados e as datas para o seu lanamento.
Pode ser que no haja um lanamento agendado no final de cada iterao do Sprint. s vezes, a release
pode ser planejada aps a concluso de um grupo de iteraes do Sprint. Dependendo da estratgia da
organizao, as Sesses de Planejamento da Release de projetos podem ser motivadas pela
funcionalidade, onde o objetivo a entrega, uma vez que um conjunto pr-determinado de funcionalidade
seja desenvolvido, ou, o planejamento pode ser motivado pela data, onde a release acontece em um data
pr-definida. A entrega deve ser liberada quando oferece o valor do negcio suficiente para o cliente.

8.6.3.2 Durao do Sprint*

Com base nas vrias entradas, incluindo os requisitos de negcio e o Cronograma de Planejamento da
Release, o Dono do Produto e o Time Scrum decidem sobre a durao dos Sprints para o projeto. Uma vez
determinada, a durao do Sprint normalmente fixada para o projeto.

178 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


8 INICIAR

No entanto, a durao do Sprint pode ser alterada, da maneira que o Dono do Produto e o Scrum Team
considerem adequada. No incio do projeto podem ainda haver testes para encontrar-se a durao ideal do
Sprint. Posteriormente no projeto, uma mudana na durao do Sprint normalmente significa que o mesmo
pode ser reduzido, devido a melhorias no ambiente do projeto.

Um Sprint pode ser Time-boxed de 1 a 6 semanas. No entanto, para obter o mximo possvel de benefcios
de um projeto Scrum, sempre recomendvel manter o Sprint Time-boxed em 4 semanas, a menos que
existam projetos com requisitos muito estveis, onde os Sprints podem ser estendidos para at 6 semanas.

O impacto da mudana esperada na durao do Sprint est descrito na seo 6.5.1

8.6.3.3 Clientes-alvo para a Release

Nem todos os lanamentos tero como alvo todos os stakeholders ou usurios. O Stakeholder pode optar
por limitar certos lanamentos para um subconjunto de usurios. O Plano da Release deve especificar os
clientes-alvo para o lanamento.
8

8.6.3.4 Backlog do Produto Priorizado e Refinado

O Backlog Priorizado do Produto, desenvolvido no processo de Criar o Backlog Priorizado do Produto, pode
ser refinado neste processo. Podendo haver clarificao adicional sobre as Estrias de Usurio no Backlog
Priorizado do Produto aps a realizao das Sesses de Planejamento da Release, feitas pelo Time Central
do Scrum e pelo(s) Stakeholder(s).

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 179


8 INICIAR

8.7 Fase do Diagrama de Fluxo de Dados

Figura 8-16: Fase de IniciarDiagrama de Fluxo de Dados

180 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9. PLANEJAR E ESTIMAR
A fase de Planejar e Estimar consiste nos processos relacionados ao planejamento e estimativa de tarefas,
que incluem Criar as Estrias de Usurio, Aprovar, Estimar e Comprometer as Estrias de Usurio, Criar as
Tarefas, Estimar as Tarefas, e Criar o Backlog do Sprint.

Planejar e Estimar, conforme Um Guia para o conhecimento em Scrum (Guia SBOK), aplicvel ao
seguinte:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Para facilitar a melhor aplicao do framework Scrum, este captulo identifica as entradas, ferramentas e 9
sadas de cada processo como "obrigatrias" ou "opcionais". As entradas, ferramentas e sadas, indicadas
por asteriscos (*), so obrigatrias, enquanto que as sem asteriscos, so opcionais.

Recomenda-se que o Time Scrum e os indivduos que esto sendo introduzidos aos processos e framework
Scrum, concentrem-se principalmente nas entradas, ferramentas e sadas obrigatrias; enquanto que os
Donos do Produto, Scrum Masters, e outros profissionais mais experientes em Scrum, devem esforar-se
para obter um conhecimento mais profundo da informao contida neste captulo inteiro. Tambm
importante perceber que, apesar de todos os processos serem definidos exclusivamente no Guia SBOK ,
eles no so necessariamente realizados sequencialmente ou separadamente. As vezes, pode ser mais
conveniente combinar alguns processos, dependendo dos requisitos especficos de cada projeto.

Este captulo escrito a partir da perspectiva de um Time Scrum, que est trabalhando em um Sprint, para
produzir Entregveis potencialmente utilizveis, como parte de um projeto maior. No entanto, a informao
descrita igualmente aplicvel a projetos, programas e portflios inteiros. As informaes adicionais
relativas utilizao do Scrum para projetos, programas e portflios esto disponveis do captulo 2 ao 7,
que abrangem os princpios do Scrum e os aspectos do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 181


9 PLANEJAR E ESTIMAR

A figura 9-1 fornece uma viso geral dos processos da fase de Planejar e Estimar:

9.1 Criar as Estrias de UsurioNesse processo, as Estrias de Usurio e os Critrios de Aceitao da


Estria de Usurio so criados. As Estrias de Usurio so geralmente escritas pelo Dono do Produto e so
projetadas para assegurar que os requisitos do cliente sejam claramente descritos e possam ser totalmente
compreendidos por todos os stakeholders. Workshops de Estria de Usurio podero ser realizados,
envolvendo o trabalho dos membros do Time Scrum na criao das Estrias de Usurio. As Estrias de
Usurio so incorporadas no Backlog Priorizado do Produto.

9.2 Aprovar, Estimar, e Comprometer as Estrias de UsurioNesse processo, o Dono do Produto


aprova as Estrias de Usurio para o Sprint. Em seguida, o Scrum Master e o Time Scrum estimam os
esforos necessrios para desenvolver a funcionalidade descrita em cada Estria de Usurio. Por fim, o
Time Scrum se compromete a entregar os requisitos do cliente sob a forma de Estrias de Usurio
aprovadas, estimadas, e comprometidas.

9.3 Criar as TarefasNesse processo, as Estrias de Usurio Aprovadas, Estimadas, e Comprometidas,


so divididas em tarefas especficas, e transformadas em uma Lista de Tarefas. Muitas vezes, uma
Reunio de Planejamento de Tarefas realizada para este fim.

9.4 Estimar as TarefasNesse processo, o Time Central do Scrum, em um Workshop de Estimativa de


tarefas, estima o esforo necessrio para realizar cada tarefa na Lista de Tarefas. O resultado deste
processo a Lista de Tarefas com Esforo Estimado.

9.5 Criar o Backlog do SprintNeste processo, o Time Central do Scrum organiza uma Reunio de
Planejamento do Sprint, onde o grupo cria um Backlog do Sprint contendo todas as tarefas a serem
concludas no Sprint.

182 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.1 Criar a Estria de Usurio 9.2 Aprovar, Estimar e Comprometer 9.3 Criar as Tarefas
as Estrias de Usurio
ENTRADAS ENTRADAS ENTRADAS
1. Time Central de Scrum* 1. Time Central de Scrum* 1. Time Central do Scrum*
2. Backlog Priorizado do Produto* 2. Estrias de Usurio* 2. Estrias de Usurio Aprovadas,
3. Critrios de Pronto* 3. Critrios de Aceitao da Estria de Estimadas e Comprometidas*
4. Personas* Usurio*
5. Stakeholder(s) 4. Recomendaes do Scrum Guidance FERRAMENTAS
6. pico(s) Body 1. Reunies de Planejamento de Tarefas*
7. Requisito de Negcio 2. Cartas de ndice
8. Leis e Regulamentos FERRAMENTAS 3. Decomposio
9. Contratos Aplicveis 1. Reunies do Grupo de Usurios* 4. Determinao de Dependncia
10. Recomendaes do Scrum Guidance 2. Planejamento Poker
Body 3. Fist of Five SADAS
FERRAMENTAS 4. Pontos de Estimativa de Custo 1. Lista de Tarefas*
1. Expertise de Escrever a Estria de 5. Outras Tcnicas de Estimativa 2. Estrias de Usurio Aprovadas,
Usurio* 6. Expertise do Scrum Guidance Body Estimadas e Comprometidas
2. Workshops da Estria de Usurio Atualizadas
3. Reunies do Grupo de Usurios SADAS 3. Dependncias
4. Reunies do Grupo de Foco 1. Estrias de Usurio Aprovadas,
5. Entrevistas de Usurios ou Clientes Estimadas e Comprometidas*
6. Questionrios
7. Mtodos de Estimativa da Estria de
Usurio
8. Expertise do Scrum Guidance Body
SADAS 9
1. Estrias de Usurio*
2. Critrios de Aceitao da Estria de
Usurio*
3. Backlog Priorizado do Produto Atualizado
4. Personas Atualizadas ou Refinadas

9.4 Estimate Tasks 9.5 Criar o Backlog do Sprint

ENTRADAS ENTRADAS
1. Time Central do Scrum* 1. Time Central do Scrum*
2. Lista de Tarefas* 2. Lista de Tarefas de Esforo Estimado*
3. Critrios de Aceitao da Estria de 3. Durao do Sprint*
Usurio 4. Velocidade do Sprint Anterior
4. Dependncias 5. Dependncias
5. Riscos Identificados 6. Calendrio do Time
6. Recomendaes do Scrum Guidance FERRAMENTAS
Body 1. Reunies de Planejamento do Sprint*
FERRAMENTAS 2. Ferramentas de Acompanhamento do
1. Reunies de Estimativa de Tarefas* Sprint
2. Critrios de Estimativa* 3. Medidas de Acompanhamento do Sprint
3. Planejamento Poker SADAS
4. Fist of Five 1. Backlog do Sprint*
5. Outras Tcnicas de Estimativa de 2. Grfico Burndown do Sprint*
Tarefas
SADAS
1. Lista de Tarefas de Esforo Estimado*
2. Lista de Tarefas Atualizada

Figura 9-1: Viso Geral de Planejar e Estimar

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 183


9 PLANEJAR E ESTIMAR

A figura 9-2 abaixo demonstra as entradas, ferramentas e sadas obrigatrias para os processos na fase
Planejar e Estimar.

9.1 Criar a Estria de Usurio 9.2 Aprovar, Estimar e 9.3 Criar as Tarefas
Comprometer as Estrias de
Usurio
ENTRADAS ENTRADAS ENTRADAS
1. Time Central de Scrum* 1. Time Central de Scrum* 1. Time Central do Scrum*
2. Backlog Priorizado do Produto* 2. Estrias de Usurio* 2. Estrias de Usurio Aprovadas,
3. Critrios de Pronto* 3. Critrios de Aceitao da Estria Estimadas e Comprometidas*
4. Personas* de Usurio* FERRAMENTAS
FERRAMENTAS FERRAMENTAS 1. Reunies de Planejamento de
1. Expertise de Escrever a Estria de 1. Reunies do Grupo de Usurios* Tarefas*
Usurio* SADAS SADAS
SADAS 1. Estrias de Usurio Aprovadas, 1. Lista de Tarefas*
1. Estrias de Usurio* Estimadas e Comprometidas*
2. Critrios de Aceitao da Estria
de Usurio*

9.4 Estimar as Tarefas 9.5 Criar o Backlog do Sprint

ENTRADAS ENTRADAS
1. Time Central do Scrum* 1. Time Central do Scrum*
2. Lista de Tarefas* 2. Lista de Tarefas de Esforo
FERRAMENTAS Estimado*
1. Reunies de Estimativa de Tarefas* 3. Durao do Sprint*
2. Critrios de Estimativa*
FERRAMENTAS
SADAS 1. Reunies de Planejamento do
1. Lista de Tarefas de Esforo Estimado*
Sprint*
SADAS
1. Backlog do Sprint*
2. Grfico Burndown do Sprint*

Figura 9-2: Viso Geral de Planejar e Estimar (Fundamentos)

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

184 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.1 Criar a Estria de Usurio


A figura 9-3 mostra todas as entradas, ferramentas e sadas do processo de Criar as Estrias de Usurio.

1. Time Central de Scrum* 1. Expertise de Escrever a Estria 1. Estrias de Usurio*


2. Backlog Priorizado do Produto* de Usurio* 2. Critrios de Aceitao da Estria
3. Critrios de Pronto* 2. Workshops da Estria de Usurio de Usurio*
4. Personas* 3. Reunies do Grupo de Usurios 3. Backlog Priorizado do Produto
5. Stakeholder(s) 4. Reunies do Grupo de Foco Atualizado
6. pico(s) 5. Entrevistas de Usurios ou 4. Personas Atualizadas ou
7. Requisito de Negcio Clientes Refinadas
8. Leis e Regulamentos 6. Questionrios
9. Contratos Aplicveis 7. Mtodos de Estimativa da Estria
10. Recomendaes do Scrum de Usurio
Guidance Body 8. Expertise do Scrum Guidance
Body 9
Figura 9-3: Criar as Estrias de UsurioEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 185


9 PLANEJAR E ESTIMAR

Figura 9-4: Criar as Estrias de UsurioDiagrama de Fluxo de Dados

186 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.1.1 Entradas

9.1.1.1 Time Central de Scrum*

Descrito na seo 8.4.1.1.

9.1.1.2 Backlog Priorizado do Produto*

Descrito na seo 8.5.3.1.

9.1.1.3 Critrios de Pronto*

Descrito na seo 8.5.3.2.

9.1.1.4 Personas*
9
Descrito na seo 8.4.3.2.

9.1.1.5 Stakeholder(s)

Descrito na seo 8.2.3.2.

9.1.1.6 pico(s)

Descrito na seo 8.4.3.1.

9.1.1.7 Requisito de Negcio

Descrito na seo 8.5.1.7.

9.1.1.8 Leis e Regulamentos

Descrito na seo 8.4.1.8.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 187


9 PLANEJAR E ESTIMAR

9.1.1.9 Contratos Aplicveis

Descrito na seo 8.4.1.9.

9.1.1.10 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

No processo de Criar as Estrias de Usurio, as Recomendaes do Scrum Guidance Body podem incluir
informaes sobre as regras, regulamentos, padres e melhores prticas, necessrias na criao de
Estrias de Usurio eficazes.

9.1.2 Ferramentas

9.1.2.1 Expertise de Escrever a Estria de Usurio*

O Dono do Produto, com base na sua interao com os stakeholders, conhecimento do negcio e expertise,
e inputs do time, desenvolve as Estrias de Usurio que formaro o primeiro Backlog Priorizado do Produto
para o projeto. O Backlog Priorizado do Produto representa a soma total do que deve ser concludo para o
projeto. O objetivo deste exerccio criar as Estrias de Usurio elaboradas e refinadas que podem ser
aprovadas, estimadas e comprometidas pelo Time Scrum. s vezes, o Dono do Produto pode trazer um
Analista de Negcios para ajudar a escrever as Estrias de Usurio.

Embora o Dono do Produto seja o responsvel principal por escrever as Estrias de Usurio, um Workshop
de Escrita da Estria de usurio pode ser realizado.

9.1.2.2 Workshops da Estria de Usurio

Descrito na seo 8.4.2.2.

9.1.2.3 Reunies do Grupo de Usurios

Descrito na seo 8.4.2.1.

188 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.1.2.4 Reunies do Grupo de Foco

As Reunies do Grupo de Foco so uma tcnica qualitativa para avaliar e entender as necessidades e
expectativas dos usurios sobre um produto proposto. Um pequeno grupo de usurios selecionado para
formar o grupo de foco. Este grupo pode ser selecionado aleatoriamente a partir de um grande grupo de
usurios ou pode ser selecionado especificamente para representar todas as Personas (o pblico-alvo). As
Reunies do Grupo de Foco normalmente aderem a um determinado formato, no qual perguntas so feitas
ao grupo que depois, discute entre si. Cada Reunio do Grupo de Foco pode ter suas prprias regras de
discusso, conforme decidido pelos organizadores. Estas reunies so geralmente realizadas na presena
de um moderador.

9.1.2.5 Entrevistas de Usurios ou Clientes

Descrito na seo 8.4.2.4.

9.1.2.6 Questionrios
9
Descrito na seo 8.4.2.5.

9.1.2.7 Mtodos de Estimativa da Estria de Usurio

Todas as ferramentas utilizadas no processo de Aprovar, Estimar e Comprometer as Estrias de Usurio


(conforme descrito na seo 9.2.2) podem ser usadas na criao de estimativas de alto nvel para os
pico(s) quando o Backlog Priorizado do Produto criado. Algumas destas ferramentas so importantes:

1. Reunies de Grupo de Usurios


2. Planejamento Poker
3. Fist of Five
4. Pontos para a Estimativa de Custos
5. Outras Tcnicas de Estimativa

9.1.2.8 Expertise do Scrum Guidance Body

Descrito na seo 8.4.2.7.

Durante a criao de Estrias de Usurio, a Expertise do Scrum Guidance Body pode relacionar-se com as
regras e regulamentos documentados; ou padres e melhores prticas para a criao de Estrias de

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 189


9 PLANEJAR E ESTIMAR

Usurio. Tambm pode existir um time de especialistas no assunto, que podem ajudar o Dono do Produto
ou fornecem orientaes sobre como criar as Estrias de Usurio. Este time pode incluir Analistas de
Negcios, Arquitetos, Desenvolvedores Snior, Especialistas do Scrum, ou outras pessoas experientes.
Este grupo de especialistas geralmente no faz parte do time que vai trabalhar em um projeto especfico,
pois tende a se movimentar de um projeto para outro e orientando os Times Scrum, se for necessrio.

9.1.3 Sadas

9.1.3.1 Estrias de Usurio*

As Estrias de Usurio aderem uma estrutura especfica pr-definida, uma maneira simples de documentar
os requisitos e desejos, as funcionalidades para o usurio final. Uma Estria de Usurio explica trs coisas
sobre a exigncia: Quem, O qu, e Por qu. Os requisitos expressos nas Estrias de Usurio so
declaraes curtas, simples e fceis de entender. O formato padro, pr-definido resulta em uma melhor
comunicao entre os stakeholders, e em melhores estimativas pelo time. Algumas Estrias de Usurio
podem ser muito grandes para serem trabalhadas dentro de um nico Sprint. Estas Estrias de Usurio
grandes so frequentemente chamadas de picos. Uma vez que os picos surgem no Backlog Priorizado
do Produto (para serem concludos em um prximo Sprint), eles so transformados em Estrias de Usurio
menores.

O Backlog Priorizado do Produto uma lista dinmica que atualizada continuamente devido redefinio
de prioridades nas Estrias de Usurio novas, atualizadas, refinadas e s vezes, excludas. Essas
atualizaes no backlog so tipicamente o resultado da mudanas de requisitos de negcios.

Consulte tambm a seo 8.5.3.1 para obter mais informaes sobre o Backlog Priorizado do Produto.

Formato da Estria de Usurio:

Enquanto <papel/persona>, Eu deveria ser capaz de solicitar um <requisito> afim de que adquirir um <
benefcio>.

Exemplo de uma Estria de Usurio:

Enquanto administrador do banco de dados, eu deveria ser capaz de reverter um nmero selecionado
de atualizaes, para que a verso desejada seja restaurada.

190 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.1.3.2 Critrios de Aceitao da Estria de Usurio*

Cada Estria de Usurio possui Critrios de Aceitao associados. As Estrias de Usurio so subjetivas,
de modo que os Critrios de Aceitao fornecem a objetividade necessria para a Estria de Usurio a ser
considerada como Pronta ou no Pronta durante a Reviso do Sprint. Os Critrios de Aceitao fornecem
clareza para o time sobre o que se espera de uma Estria de Usurio, remove a ambiguidade dos requisitos
e contribui no alinhamento de expectativas. O Dono do Produto define e comunica os Critrios de Aceitao
para o Time Scrum. Durante as Reunies de Reviso do Sprint, os Critrios de Aceitao fornecem ao
Dono do Produto o contexto necessrio para decidir se uma Estria de Usurio foi concluda
satisfatoriamente. O Scrum Master responsvel em garantir que o Dono do Produto no mude, no meio
de um Sprint, os Critrios de Aceitao de uma Estria de Usurio comprometida.

9.1.3.3 Backlog Priorizado do Produto Atualizado

O Backlog Priorizado do Produto criado no processo de Criar o Backlog Priorizado do Produto atualizado
com informaes sobre as Estrias de Usurio, pico(s), estimativas das Estrias de Usurio, e Critrios de
Aceitao da Estria de Usurio.

O Backlog Priorizado do Produto descrito na seo 8.5.3.1. 9

9.1.3.4 Personas Atualizadas ou Refinadas

As Personas so inicialmente criadas durante o processo de Desenvolver os pico(s). Enquanto as Estrias


de Usurio esto sendo escritas, o Time Scrum pode chegar a uma deciso coletiva de que algumas
dessas Personas iniciais so inadequadas e precisam ser refinadas. Normalmente, se o refinamento de
Personas for necessrio, este ser feito prximo ao final do processo de Criar as Estrias de Usurio.

As Personas so descritas na seo 8.4.3.2.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 191


9 PLANEJAR E ESTIMAR

9.2 Aprovar, Estimar e Comprometer as Estrias de Usurio


A figura 9-5 abaixo mostra todas as entradas, ferramentas e sadas do processo de Aprovar, Estimar e
Comprometer as Estrias de Usurio.

1. Time Central de Scrum* 1. Reunies do Grupo de 1. Estrias de Usurio Aprovadas,


2. Estrias de Usurio* Usurios* Estimadas e Comprometidas*
3. Critrios de Aceitao da Estria 2. Planejamento Poker
de Usurio* 3. Fist of Five
4. Recomendaes do Scrum 4. Pontos de Estimativa de Custo
Guidance Body 5. Outras Tcnicas de Estimativa
6. Expertise do Scrum Guidance
Body

Figura 9-5: Aprovar, Estimar, e Comprometer as Estrias de UsurioEntradas, Ferramentas, e Sadas

Figura 9-6: Aprovar, Estimar, e Comprometer as Estrias de UsurioDiagrama de Fluxo de Dados

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

192 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.2.1 Entradas

9.2.1.1 Time Central de Scrum*

Descrito na seo 8.4.1.1.

9.2.1.2 Estrias de Usurio*

Descrito na seo 9.1.3.1.

As Estrias de Usurio tem estimativas de alto nvel dos processos de Criar o Backlog Priorizado do
Produto e de Criar as Estrias de Usurio. Estas estimativas so usadas pelo Dono do Produto na criao
da lista de Estrias de Usurio aprovadas que so estimadas com maior preciso pelo Time Scrum. Tais
Estrias de Usurio estimadas so ento, comprometidas pelo Time Scrum para serem concludas no
Sprint.

9.2.1.3 Critrios de Aceitao da Estria de Usurio* 9

Descrito na seo 9.1.3.2.

9.2.1.4 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

No processo de Aprovar, Estimar e Comprometer as Estrias de Usurio, as Recomendaes do Scrum


Guidance Body podem incluir informaes sobre as regras, regulamentos, padres e melhores prticas
necessrias para Aprovar, Estimar e Comprometer as Estrias de Usurio efetivamente.

9.2.2 Ferramentas

9.2.2.1 Reunies do Grupo de Usurios*

Descrito na seo 8.4.2.1.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 193


9 PLANEJAR E ESTIMAR

9.2.2.2 Planejamento Poker

O Planejamento Poker, tambm chamado de Poker da Estimativa, uma tcnica de estimativa que usa o
consenso para estimar os tamanhos relativos das Estrias de Usurios, ou o esforo necessrio para cri-
las.

No Planejamento Poker, a cada membro do time atribudo um baralho de cartas. Cada carta numerada
em uma sequncia e os nmeros representam a complexidade do problema, em termos de tempo ou
esforo, conforme estimado pelo membro do time. O Dono do Produto escolhe uma Estria de Usurio do
Backlog Priorizado do Produto e apresenta para o time. Os membros do Time Scrum avaliam a Estria de
Usurio e tentam compreend-la melhor antes de fornecer a sua estimativa com relao ao
desenvolvimento. Em seguida, cada membro escolhe uma carta do baralho que representa a sua estimativa
para a Estria de Usurio. Se a maioria, ou todos os membros do time, selecionarem a mesma carta, ento,
a estimativa indicada nesta carta ser a estimativa para a Estria de Usurio. Se no houver um consenso,
os membros do time discutem as razes pelas quais selecionaram diferentes cartas ou estimativas. Aps
essa discusso eles escolhem novamente uma carta. Esta sequncia continua at que todas as suposies
sejam compreendidas, mal-entendidos sejam resolvidos e o consenso ou acordo seja alcanado.

O Planejamento Poker defende uma maior interao e melhor comunicao entre os participantes.
Facilitando o pensamento independente pelos participantes, evitando assim o fenmeno de pensamento em
grupo.

9.2.2.3 Fist of Five

O Fist of Five um mecanismo simples e rpido para chegar a um consenso em grupo e para conduzir uma
discusso. Aps a discusso inicial sobre uma determinada proposta ou deciso pendente, usando os seus
dedos, os membros do Time Scrum so convidados a votar em uma escala de 1 a 5. O valor de uso desta
tcnica no est apenas na construo do consenso, mas tambm na conduo de discusses, pois cada
membro do time convidado a explicar a razo de seu ranking. Eles tambm tm a oportunidade de
expressar quaisquer problemas ou preocupaes. Assim que o time discutir o assunto, uma deciso
coletiva ser tomada.

O nmero de dedos usados na votao indica o nvel de acordo e desejo de discusso:

1. Um dedo: Eu no concordo com a concluso do grupo e tenho dvidas.


2. Dois dedos: Eu no concordo com a concluso do grupo e gostaria de discutir alguns problemas
menores.
3. Trs dedos: Eu no tenho certeza e gostaria de apoiar a concluso de consenso do grupo.
4. Quatro dedos: Eu concordo com a concluso do grupo e gostaria de discutir alguns problemas
menores.
5. Cinco dedos: Eu concordo plenamente com a concluso do grupo.

194 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.2.2.4 Pontos de Estimativa de Custo

A Estimativa de custos pode ser realizada atravs da utilizao de unidades relativas (por exemplo,
estimativas de esforos) ao invs de unidades absolutas (ou seja, dos custos reais incorridos). Com a
finalidade de estimar o custo de implementao de uma Estria de Usurio, o Time Scrum pode usar
pontos da Estria. Quando isso feito, o custo estimado para cada tarefa ser sob a forma de pontos, ao
invs de unidades monetrias. A fim de fazer isso com sucesso, o Time Scrum deve identificar uma linha
base para a Estria de Usurio, a qual todos os membros do time podem se relacionar. Uma vez que esta
linha base seja identificada, todas as estimativas de custo para as Estrias de Usurio devem ser feitas
com relao a essa linha base. Estas estimativas permanecem fixas ao longo de um Sprint, j que os times
no devem fazer modificaes durante o Sprint.

9.2.2.5 Outras Tcnicas de Estimativa

9.2.2.5.1 Wideband Delphi

A Wideband Delphi uma tcnica de estimativa baseada pelo grupo, para determinar a quantidade de
trabalho que est envolvido, e quanto tempo vai demorar para esse trabalho ser concludo. Os indivduos
dentro de um time anonimamente fornecem estimativas para cada recurso, e essas estimativas iniciais so 9
ento adicionadas em um grfico. O time ento, discute os fatores que influenciaram em suas estimativas e
procedem para uma segunda rodada de estimativas. Este processo repetido at que as estimativas dos
indivduos sejam similares e que um consenso possa ser alcanado para uma estimativa final.

O Planejamento Poker (conforme descrito na seo 9.2.2.2) um exemplo de uma tcnica Wideband
Delphi. Tambm importante notar que o input do indivduo coletado por um mecanismo que evita o
pensamento em grupo. Em seguida, os inputs individuais so utilizados para uma deciso em grupo.

9.2.2.5.2 Tamanho Relativo/Pontos da Estria

Alm de serem usados para estimar o custo, os pontos da estria tambm podem ser usados para estimar
o tamanho geral de uma Estria de Usurio ou caracterstica. Essa abordagem atribui um valor de ponto da
estria baseado em uma avaliao geral do tamanho de uma Estria de Usurio, considerando o risco, a
quantidade de esforo exigido e o nvel de complexidade. Esta avaliao ser realizada pelo Time Scrum e
um valor de ponto da estria ser atribudo. Uma vez que a avaliao feita para uma Estria de Usurio
do Backlog Priorizado do Produto, o Time Scrum pode ento avaliar outras Estrias de Usurios
relacionadas a essa primeira estria. Por exemplo, uma caracterstica com um valor de ponto da estria
igual a 2, deve ser duas vezes mais difcil de ser concluda, do que uma caracterstica com um valor de
ponto da estria igual a 1; uma caracterstica com um valor de ponto da estria igual a 3, deve ser trs
vezes mais difcil de ser concluda, do que uma caracterstica com um valor de ponto da estria igual a 1.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 195


9 PLANEJAR E ESTIMAR

9.2.2.5.3 Estimativa de Afinidade

A Estimativa de Afinidade uma tcnica utilizada para estimar rapidamente um grande nmero de Estrias
de Usurio. Usando notas auto-colante ou cartes de ndice com durex, o time coloca as Estrias de
Usurio em uma parede ou em outra superfcie, na ordem do menor para o maior. Para isso, cada membro
do time comea com um subconjunto de Estrias de Usurio do Backlog Priorizado do Produto colocando
de acordo com o tamanho relativo. Esse posicionamento inicial feito em silncio. Depois que todo mundo
coloca as suas Estrias de Usurio na parede, o time as analisa e pode reposicion-las de acordo com o
que achar mais apropriado. Esta segunda parte do exerccio envolve discusso. Finalmente, o Dono do
Produto vai indicar algumas categorias de dimensionamento na parede. Essas categorias podem ser
pequena, mdia ou grande, ou podem ser numeradas usando valores de ponto da estria para indicar o seu
tamanho relativo. O time, ento, mover as Estrias de Usurio para essas categorias como parte da etapa
final desse processo. Alguns dos principais benefcios desta abordagem so que o processo muito
transparente, visvel para todos, e fcil de conduzir.

9.2.2.5.4 Estimativa de Intervalo

As estimativas para os projetos devem ser apresentadas em intervalos. Nmeros exatos podem dar a
impresso de serem altamente precisos, quando na verdade podem no ser. De fato, as estimativas, por
definio, so entendidas como no sendo exatamente precisas. A Estimativa de Intervalo deve ser
baseada no nvel de confiana que o time tem em cada estimativa. O intervalo pode ser estreito quando o
time est confiante, e amplo, quando o time no est to confidente.

9.2.2.6 Expertise do Scrum Guidance Body

Descrito na seo 8.4.2.7.

Podem surgir durante este processo, conflitos relacionados as estimativas para completar certas Estrias
de Usurio, devido ao fato de que as perspectivas dos membros do time podem ser diferentes e porque o
time pode ainda no ter experincia suficiente para estimar os Sprints. Nestas situaes, a experincia e a
expertise do Scrum Guidance Body pode ajudar na resoluo de conflitos.

196 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.2.3 Sadas

9.2.3.1 Estrias de Usurio Aprovadas, Estimadas e Comprometidas*

As Estrias de Usurio, que so os inputs para este processo, tem estimativas de alto nvel dos processos
de Criar o Backlog Priorizado do Produto e Criar as Estrias de Usurio. Essas estimativas so utilizadas
pelo Dono do Produto para aprovar as Estrias de Usurio para o Sprint.

Deve-se notar que o Dono do Produto o responsvel em garantir que as Estrias de Usurio aprovadas
agregam valor e atendam s necessidades e requisitos dos stakeholders. Uma vez que aprovadas, as
Estrias de Usurio so estimadas pelo time, utilizando-se as vrias tcnicas de estimativa discutidas nesta
seo. Aps esta estimativa, o time compromete-se com um subconjunto de Estrias de Usurio aprovadas
e estimadas que eles acreditam que possam completar no prximo Sprint. Estas Estrias de Usurio so
Estrias de Usurio Aprovadas, Estimadas e Comprometidas, que passaro a fazer parte do Backlog do
Sprint.

Embora o Dono do Produto aprove as Estrias de Usurio iniciais para o Sprint, a deciso final sobre quais
Estrias de Usurio especficas (juntamente com as aprovadas pelo Dono do Produto) devem ser
escolhidas para o Sprint est com o Time Scrum. O Time Scrum (com o auxlio do Dono do Produto, se for
9
necessrio) finaliza em quais Estrias de Usurio eles iro trabalhar durante o Sprint.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 197


9 PLANEJAR E ESTIMAR

9.3 Criar as Tarefas


A figura 9-7 abaixo mostra todas as entradas, ferramentas e sadas do processo de Criar as Tarefas.

1. Time Central do Scrum* 1. Reunies de Planejamento de 1. Lista de Tarefas*


2. Estrias de Usurio Aprovadas, Tarefas* 2. Estrias de Usurio Aprovadas,
Estimadas e Comprometidas* 2. Cartas de ndice Estimadas e Comprometidas
3. Decomposio Atualizadas
4. Determinao de Dependncia 3. Dependncias

Figura 9-7: Criar as TarefasEntradas, Ferramentas, e Sadas

Figura 9-8: Criar as TarefasDiagrama de Fluxo de Dados

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

198 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.3.1 Entradas

9.3.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

9.3.1.2 Estrias de Usurio Aprovadas, Estimadas e Comprometidas*

Descrito na seo 9.2.3.1.

9.3.2 Ferramentas

9.3.2.1 Reunies de Planejamento de Tarefas*

Nas Reunies de Planejamento de Tarefas, o Time Scrum se rene para planejar o trabalho a ser feito no
Sprint. O time analisa as Estrias de Usurio comprometidas que esto no topo do Backlog Priorizado do 9
Produto. O Dono do Produto est presente durante nesta reunio, caso seja necessrio um esclarecimento
com relao as Estrias de Usurio do Backlog Priorizado do Produto e para ajudar o time a tomar decises
sobre design. Esta reunio deve ser Time-boxed para ajudar a garantir que o grupo permanea focado no
tema, com uma durao padro limitada a duas horas para cada semana de durao do Sprint. Isso ajuda a
prevenir a tendncia de se concentrar em discusses que realmente devem ocorrer durante outras
reunies, como em Reunies de Planejamento da Release ou de Reviso do Sprint. No final da reunio,
todo o Time Scrum estar totalmente comprometido em entregar um subconjunto de Estrias de Usurio do
Backlog Priorizado do Produto no Sprint.

A Reunio de Planejamento de Tarefas normalmente dividida em duas sees, com um propsito


designado e ampla agenda para cada um (veja a figura 9-9)

O Dono do Produto sugere as Estrias de Usurio que devem fazer parte do Sprint
O Time Scrum determina quantas Estrias de Usurio podem ser executadas no Sprint.
Um consenso alcanado com relao as Estrias de Usurio que devem ser includas no
1a Parte Sprint.

O Time Scrum determina como transformar as Estrias de Usurio selecionadas em um


Incremento do Produto, dividindo-as em tarefas.
2a Parte O Time Scrum compromete-se com as entregas do Sprint.

Figura 9-9: Reunies de Planejamento de Tarefas

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 199


9 PLANEJAR E ESTIMAR

As Reunies de Planejamento de Tarefas podem, por vezes, tambm serem referidas como "Reunies de
Planejamento do Sprint" - essas reunies tambm podem ser combinadas com as Reunies de Estimativa
de Tarefas conforme descrito na seo 9.4.2.1

9.3.2.2 Cartas de ndice

Em Scrum, as Estrias de Usurio so escritas em pequenos cartas de ndice. Apenas detalhes essenciais
so documentados nas cartas, que podem ser usados pelo Time Scrum para colaborar e discutir. Estas
Cartas de ndice, muitas vezes descritas como Cartas da Estria, aumentam a visibilidade e transparncia e
facilitam a deteco precoce de eventuais problemas que possam surgir.

9.3.2.3 Decomposio

A Decomposio a ferramenta utilizada na diviso de tarefas de altos nveis, em tarefas mais detalhadas,
de nveis mais baixos. As Estrias de Usurio so separadas em tarefas pelos membros do Time Scrum. As
Estrias de Usurio no Backlog Priorizado do Produto devem ser suficientemente separadas em um nvel
em que possam fornecer informaes adequadas ao Time Scrum, para que o time crie entregas de Tarefas
mencionadas na Lista de Tarefas.

9.3.2.4 Determinao de Dependncia

Uma vez que o Time Scrum tenha selecionado as Estrias de Usurio para um determinado Sprint, os
membros do time devem ento considerar qualquer dependncia, incluindo as relacionadas com a
disponibilidade de pessoal, assim como qualquer dependncia tcnica. Documentar devidamente as
dependncias, ajuda o Time Scrum a determinar a ordem relativa em que as tarefas devem ser executadas
para criar as Entregas do Sprint. As dependncias tambm destacam a relao e interao entre tarefas,
ambos dentro do Time Scrum trabalhando em um determinado Sprint, com em outros Times Scrum do
projeto.

Existem inmeros tipos de dependncias: obrigatrias e discricionrias, internas e externas, ou alguma


combinao destas dependncias. Por exemplo, uma dependncia pode ser tanto obrigatria quanto
externa.

Dependncias ObrigatriasAs dependncias que so inerentes natureza do trabalho, como


uma limitao fsica, e podem ser devidas a obrigaes contratuais ou requisitos legais. Por
exemplo, o trabalho no primeiro andar no pode comear antes que a fundao do edifcio esteja
concluda. As dependncias obrigatrias tambm so comumente descritas como lgica difcil.

200 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

Dependncias DiscricionriasAs dependncias que so colocadas no fluxo de trabalho por


opo. Normalmente, as dependncias discricionrias so determinadas pelo Time Scrum, com
base em experincias passadas ou em melhores prticas sobre um assunto ou domnio. Por
exemplo, o time pode decidir completar uma tarefa antes de comear trabalhar em outra, porque
uma prtica recomendada, mas no obrigatria. Por exemplo, o time pode optar por construir as
portas e janelas antes de toda a estrutura da parede estar pronta.

Dependncias ExternasAs Dependncias Externas so aquelas relacionadas a tarefas,


atividades ou produtos que esto fora do escopo de trabalho a ser executado pelo Time Scrum,
mas que so necessrias para completar uma tarefa ou criar um entregvel do projeto. As
Dependncias Externas esto geralmente fora do controle do Time Scrum. Por exemplo, se o Time
Scrum no for responsvel por adquirir os materiais necessrios para a construo das paredes,
ento, os materiais e tarefas relacionadas sua aquisio so consideradas dependncias
externas.

Dependncias InternasAs Dependncias Internas so aquelas dependncias entre tarefas,


produtos ou atividades, que esto sob o controle do Time Scrum e no mbito do trabalho a ser
executado pelo Time Scrum. Por exemplo, a aplicao da massa corrida deve ser concluda antes
de se comear a pintar a parede. Este um exemplo de uma dependncia interna, porque ambas
9
as tarefas fazem parte do projeto. Neste caso, tambm obrigatria porque baseada em uma
limitao fsica. No possvel pintar a parede antes da massa corrida estar seca.

9.3.3 Sadas

9.3.3.1 Lista de Tarefas*

Essa uma lista abrangente, que contm todas as tarefas que o Time Scrum se comprometeu a realizar
durante o Sprint atual. Ela contm as descries de cada tarefa juntamente com as estimativas feitas
durante o processo de Criar as Tarefas. A Lista de Tarefas deve incluir quaisquer esforos de teste e
integrao, de modo que o Incremento do Produto do Sprint possa ser integrado com sucesso nas entregas
de Sprints anteriores.

Embora as tarefas sejam muitas vezes baseadas atividade, o nvel de granularidade em que as tarefas so
decompostas decidido pelo Time Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 201


9 PLANEJAR E ESTIMAR

9.3.3.2 Estrias de Usurio Aprovadas, Estimadas e Comprometidas Atualizadas

As Estrias de Usurio so atualizadas durante este processo. As atualizaes podem incluir revises da
Estria de Usurio original com estimativas base na criao de tarefas e em fatores de complexidade
discutidos durante a Reunio de Planejamento do Sprint. As Estrias de Usurio Aprovadas, Estimadas e
Comprometidas esto descritas na seo 9.2.3.1.

9.3.3.3 Dependncias

As Dependncias descrevem a relao e a interao entre as diferentes tarefas em um projeto e podem ser
classificadas como obrigatrias ou discricionrias; e internas ou externas; conforme discutido na seo
9.3.2.4.

Existem inmeras maneiras de identificar, definir e apresentar as tarefas e as suas dependncias. Dois
mtodos comuns envolvem o uso de diagramas de fluxo de produto e grficos de Gantt.

202 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.4 Estimar as Tarefas


A figura 9-10 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Estimar as
Tarefas.

1. Time Central do Scrum* 1. Reunies de Estimativa de 1. Lista de Tarefas de Esforo


2. Lista de Tarefas* Tarefas* Estimado*
3. Critrios de Aceitao da Estria 2. Critrios de Estimativa* 2. Lista de Tarefas Atualizada
de Usurio 3. Planejamento Poker
4. Dependncias 4. Fist of Five
5. Riscos Identificados 5. Outras Tcnicas de Estimativa de
6. Recomendaes do Scrum Tarefas
Guidance Body

Figura 9-10: Estimar as TarefasEntradas, Ferramentas, e Sadas


9

Figura 9-11: Estimar as TarefasDiagrama de Fluxo de Dados

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 203


9 PLANEJAR E ESTIMAR

9.4.1 Entradas

9.4.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

9.4.1.2 Lista de Tarefas*

Descrito na seo 9.3.3.1.

9.4.1.3 Critrios de Aceitao da Estria de Usurio

Descrito na seo 9.1.3.2.

O Time Scrum deve garantir que os Critrios de Aceitao definidos so adequados para as Estrias de
Usurio, e que fornecem clareza para o Time Scrum sobre os requisitos. O teste de Aceitao refere-se
avaliao da capacidade da entrega concluda em atender seus Critrios de Aceitao. Isso fornece
informaes para o Dono do Produto ajudando na tomada de decises sobre a aprovao ou rejeio de
Entregvel.

Ao desenvolver os Critrios de Aceitao da Estria de Usurio, deve-se considerar que:

Os Critrios de Aceitao no devem ser vagos, ambguos ou muito genricos.


Os Critrios de Aceitao definidos devem garantir que o time capaz de verificar se os resultados
esto alinhados com as metas e objetivos da organizao patrocinadora.

9.4.1.4 Dependncias

Descrito na seo 9.3.3.3

9.4.1.5 Riscos Identificados

Descrito na seo 8.4.3.4.

204 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.4.1.6 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

No processo de Estimar as Tarefas, as Recomendaes do Scrum Guidance Body podem incluir


informaes sobre as regras, regulamentos, padres e melhores prticas necessrias para estimar de
forma eficaz as tarefas na Lista de Tarefas.

9.4.2 Ferramentas

9.4.2.1 Reunies de Estimativa de Tarefas*

As Reunies de Estimativa de Tarefas permitem que o Time Scrum estime o esforo necessrio para
concluir uma tarefa ou um conjunto de tarefas, e estime o esforo de pessoas e outros recursos
necessrios para realizar as tarefas dentro de um determinado Sprint. Nas Reunies de Estimativa de
Tarefas, os membros do Time Scrum utilizam a Lista de Tarefas para estimar a durao e o esforo
necessrio para as Estrias de Usurio a serem concludas no Sprint.
9
O fato de que esta tcnica permite que o time tenha uma perspectiva compartilhada das Estrias de
Usurio e dos requisitos, um dos seus benefcios principais, permitindo que o time possa estimar o
esforo necessrio. A informao desenvolvida nas Reunies de Estimativa de Tarefas est includa na
Lista de Tarefas de Esforo Estimado e usada para determinar a velocidade do Sprint.

Neste workshop, o Time Scrum poder utilizar vrias tcnicas, como: decomposio, pareceres de peritos,
estimativa anloga e estimativa paramtrica.

As Reunies de Estimativa de Tarefas so tambm muitas vezes referidas como "Reunies de


Planejamento do Sprint" - essas reunies tambm podem ser combinadas com as Reunies de
Planejamento de Tarefas, conforme descrito na seo 9.3.2.1.

9.4.2.2 Critrios de Estimativa*

O objetivo principal da utilizao de Critrios de Estimativa, o de manter os tamanhos de estimativa


relativos e minimizar a necessidade de re-estimao. Os Critrios de Estimativa podem ser expressos de
vrias maneiras, tendo com dois exemplos comuns, os pontos da estria e o tempo ideal. Por exemplo, um
tempo ideal descreve normalmente o nmero de horas em que um membro do Time Scrum trabalha,
exclusivamente, no desenvolvimento de entregas do projeto, sem incluir qualquer tempo gasto em outras
atividades ou trabalho que estejam fora do projeto. Os Critrios de Estimativa fazem com que o processo de
estimar o esforo seja mais fcil para o Time Scrum e quando necessrio, permitir-lhes avaliar e tratar as
ineficincias.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 205


9 PLANEJAR E ESTIMAR

9.4.2.3 Planejamento Poker

Descrito na seo 9.2.2.2.

9.4.2.4 Fist of Five

Descrito na seo 9.2.2.3.

9.4.2.5 Outras Tcnicas de Estimativa de Tarefas

Descrito na seo 9.2.2.5.

9.4.3 Sadas

9.4.3.1 Lista de Tarefas de Esforo Estimado*

A Lista de Tarefas de Esforo Estimado uma lista de tarefas associada com as Estrias de Usurio
comprometidas, includas em um Sprint. Normalmente a preciso das estimativas varia de acordo com as
habilidades do time. O Esforo Estimado expresso em termos dos critrios de estimativa acordados pelo
time. A Lista de Tarefas de Esforo Estimado usada pelo Time Scrum durante as Reunies de
Planejamento do Sprint para criar o Backlog do Sprint e o Grfico Burndown do Sprint. Tambm usado
para determinar quando o time precisa reduzir o seu comprometimento com Estrias de Usurio, ou quando
pode assumir Estrias de Usurio adicionais durante o Planejamento do Sprint.

9.4.3.2 Lista de Tarefas Atualizada

A Lista de Tarefas, desenvolvida como parte do processo de Criar as Tarefas, inclui as estimativas iniciais
das Estria de Usurio que precisam ser revistas com base nas atividades mais detalhadas de estimativa,
realizadas no processo de Estimar as Tarefas. Tambm podem haver re-estimativas resultantes de uma
avaliao de Sprints anteriores, ou de mudana na compreenso coletiva do Time Scrum sobre as Estrias
de Usurio e requisitos.

206 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.5 Criar o Backlog do Sprint


A figura 9-12 abaixo mostra todas as entradas, ferramentas e sadas do processo de Criar o Backlog do
Sprint.

1. Time Central do Scrum* 1. Reunies de Planejamento do 1. Backlog do Sprint*


2. Lista de Tarefas de Esforo Sprint* 2. Grfico Burndown do Sprint*
Estimado* 2. Ferramentas de
3. Durao do Sprint* Acompanhamento do Sprint
4. Velocidade do Sprint Anterior 3. Medidas de Acompanhamento
5. Dependncias do Sprint
6. Calendrio do Time

Figura 9-12: Criar o Backlog do SprintEntradas, Ferramentas, e Sadas


9

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 207


9 PLANEJAR E ESTIMAR

Figura 9-13: Criar o Backlog do SprintDiagrama de Fluxo de Dados

208 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.5.1 Entradas

9.5.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

9.5.1.2 Lista de Tarefas de Esforo Estimado*

Descrito na seo 9.4.3.1.

9.5.1.3 Durao do Sprint*

Descrito na seo 8.6.3.2.

9.5.1.4 Velocidade do Sprint Anterior 9

A Velocidade do Sprint o ritmo em que o time pode concluir o trabalho em um Sprint. geralmente
expressa nas mesmas unidades utilizadas para a estimativa (pontos de estria ou tempo ideal). Um registro
sobre a Velocidade do time no Sprint mantido para cada Sprint, e utilizado como referncia em Sprints
futuros. A Velocidade do Sprint anterior torna-se o fator mais importante na determinao da quantidade de
trabalho que o time pode comprometer-se em um Sprint subsequente. Quaisquer mudanas na situao ou
nas condies desde o ltimo Sprint so contabilizadas para garantir estimativas precisas sobre a
Velocidade do Sprint para o prximo Sprint.

9.5.1.5 Dependncias

Descrito na seo 9.3.3.3.

9.5.1.6 Calendrio do Time

O Calendrio do Time contm informaes sobre a disponibilidade dos membros do time, incluindo
informaes relacionadas a frias, afastamentos, eventos importantes, e feriados.

Um dos objetivos principais da utilizao de um Calendrio do Time, acompanhar no que cada membro
do time est trabalhando durante todo o projeto. Ajudando o time no apenas no planejamento e execuo
eficiente dos Sprints, mas tambm no alinhamento dos Sprints com datas de lanamento.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 209


9 PLANEJAR E ESTIMAR

9.5.2 Ferramentas

9.5.2.1 Reunies de Planejamento do Sprint*

Durante as Reunies de Planejamento do Sprint, as Estrias de Usurio, que so aprovadas, estimadas, e


comprometidas durante o processo de Aprovar, Estimar e Comprometer as Estrias de Usurio, so
levadas para o Time Scrum para discusso. Cada membro do Time Scrum tambm utiliza uma Lista de
Tarefas de Esforo Estimado para selecionar as tarefas em que eles planejam trabalhar no Sprint, com
base em suas habilidades e experincia. O Time Scrum ainda cria o Backlog do Sprint e o Grfico
Burndown do Sprint, usando as Estrias de Usurio e a Lista de Tarefas de Esforo Estimado durante as
Reunies de Planejamento do Sprint.

9.5.2.2 Ferramentas de Acompanhamento do Sprint

importante controlar o andamento de um Sprint, e saber o que falta para o Time Scrum completar as
tarefas do Backlog do Sprint. Uma variedade de ferramentas podem ser usadas para monitorar o trabalho
em um Sprint, mas uma das mais comuns o Scrumboard, tambm conhecido como quadro de tarefas ou
grfico de progresso. O Scrumboard dividido nas seguintes sees: para Fazer (muitas vezes referido
como o Trabalho No Iniciado), Trabalho Em Andamento, e o Trabalho Concludo. Post-its representam
cada tarefa, ou Estria de Usurio so colocadas na categoria apropriada para refletir o status do trabalho.
Sendo movidas para a prxima categoria de acordo com o progresso do trabalho.

9.5.2.3 Medidas de Acompanhamento do Sprint

Medidas utilizadas em projetos Scrum incluem: a velocidade, o valor do negcio entregue, e o nmero de
estrias.

Velocidaderepresenta o nmero de Estrias de Usurio, ou nmero de funcionalidades entregues em um


nico Sprint.

Valor do negcio entreguemede o valor das Estrisa de Usurio entregues, a partir da perspectiva do
negcio.

Nmero de estriasrefere-se a quantidade de Estrias de Usurio que so entregues como parte de um


nico Sprint. Pode ser expresso em termos de contagem simples ou contagem ponderada.

210 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


9 PLANEJAR E ESTIMAR

9.5.3 Sadas

9.5.3.1 Backlog do Sprint*

Uma lista de tarefas a serem executadas pelo Time Scrum no prximo Sprint chamada de Backlog do
Sprint.

uma prtica comum que o Backlog do Sprint seja representado em um Scrumboard ou quadro de tarefas,
o que proporciona uma representao constantemente visvel do status das Estrias de Usurio no backlog.
Tambm esto includos no Backlog do Sprint os riscos associados com as vrias tarefas. Todas as
atividades de mitigao para tratar os riscos identificados tambm devero ser includas como tarefas no
Backlog do Sprint.

Uma vez que o Backlog do Sprint seja finalizado e comprometido pelo Time Scrum, as Estrias de Usurio
novas no devem ser adicionadas; no entanto, as tarefas das Estrias de Usurio comprometidas que
podem ter sido perdidas ou negligenciadas, podem precisar serem adicionadas. Se novos requisitos
surgirem durante o Sprint, eles sero adicionados no Backlog Priorizado do Produto geral e includos em
um futuro Sprint.

9
9.5.3.2 Grfico Burndown do Sprint*

O Grfico Burndown do Sprint um grfico que mostra a quantidade de trabalho restante durante o
desenvolvimento do Sprint. O Grfico inicial Burndown do Sprint acompanhado por um burndown
planejado. O Grfico Burndown do Sprint deve ser atualizado como o trabalho que foi concludo no final de
cada dia. Este grfico mostra o progresso que tem sido feito pelo Time Scrum e tambm permite a deteco
de estimativas que podem ter sido incorretas. Se o Grfico Burndown do Sprint mostra que o Time Scrum
no ser capaz de terminar as tarefas do Sprint em tempo, o Scrum Master deve identificar quaisquer
obstculos ou impedimentos para a concluso bem sucedida e tentar remov-los.

Um grfico relacionado um Grfico Burnup do Sprint. Ao contrrio do Grfico Burndown do Sprint que
mostra a quantidade de trabalho restante, o Grfico Burnup do Sprint retrata o trabalho realizado como
parte do Sprint.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 211


9 PLANEJAR E ESTIMAR

9.6 Fase do Diagrama de Fluxo de Dados

Figura 9-14: Fase de Planejar e EstimarDiagrama de Fluxo de Dados

212 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10. IMPLEMENTAR
A fase de Implementar est relacionada com a execuo das tarefas e atividades para criar o produto de
um projeto. Essas atividades incluem a criao de vrias entregas, a realizao de Reunies Dirias, e o
refinamento (reviso, ajuste fino, e atualizao regular) do Backlog do Produto em intervalos regulares.

Implementar, conforme definido em Um Guia para o Conhecimentos em Scrum (Guia SBOK ), aplicvel
ao seguinte:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Para facilitar a melhor aplicao do framework Scrum, este captulo identifica as entradas, ferramentas e
sadas de cada processo como "obrigatrias" ou "opcionais". As entradas, ferramentas e sadas, indicadas
por asteriscos (*), so de obrigatrias, enquanto que as sem asteriscos, so opcionais. 10
Recomenda-se que o Time Scrum e os indivduos que esto sendo introduzidos aos processos e framework
Scrum, se concentrem principalmente nas entradas, ferramentas e sadas obrigatrias; enquanto que os
Donos do Produto, Scrum Masters, e outros profissionais mais experientes em Scrum, devem se esforam
para obter um conhecimento mais profundo da informao contida neste captulo inteiro. Tambm
importante perceber que, apesar de todos os processos serem definidos exclusivamente no Guia SBOK ,
eles no so necessariamente realizados sequencialmente ou separadamente. As vezes, pode ser mais
conveniente combinar alguns processos, dependendo dos requisitos especficos de cada projeto.

Este captulo escrito a partir da perspectiva de um Time Scrum, que est trabalhando em um Sprint, para
produzir Entregveis potencialmente utilizveis, como parte de um projeto maior. No entanto, a informao
descrita igualmente aplicvel a projetos, programas e portflios inteiros. As informaes adicionais
relativas utilizao do Scrum para projetos, programas e portflios esto disponveis do captulo 2 ao 7,
que abrangem os princpios do Scrum e os aspectos do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 213


10 IMPLEMENTAR

A figura 10-1 fornece uma viso geral dos processos em fase de Implementar:

10.1 Criar os EntregveisNeste processo, o Time Scrum trabalha nas tarefas no Backlog do Sprint para
criar os Entregveis do Sprint. Um Scrumboard, ou quadro de Scrum, frequentemente utilizada para
acompanhar o trabalho e as atividades sendo concludas. Questes ou problemas sendo enfrentados pelo
Time Scrum podem ser atualizados em um Log de Impedimentos.

10.2 Conduzir a Reunio DiriaNeste processo, uma reunio Time-boxed e altamente focada
realizada todos os dias. Esta reunio chamada de Reunio Diria, um frum para o Time Scrum com a
oportunidade de atualizar uns aos outros sobre o seu progresso e quaisquer impedimentos que possam
estar enfrentando.

10.3 Refinamento do Backlog Priorizado do ProdutoNeste processo, o Backlog Priorizado do Produto


continuamente atualizado e mantido. Uma Reunio de Reviso do Backlog Priorizado do Produto pode
ser realizada, em que quaisquer mudanas ou atualizaes no backlog devem ser discutidas e
incorporadas no Backlog Priorizado do Produto conforme apropriado.

214 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.1 Criar os Entregveis 10.2 Conduzir a Reunio Diria 10.3 Refinamento do Backlog
Priorizado do Produto
ENTRADAS ENTRADAS ENTRADAS
1. Time Central do Scrum* 1. Time Scrum* 1. Time Central do Scrum*
2. Backlog do Sprint* 2. Scrum Master* 2. Backlog Priorizado do Produto*
3. Scrumboard* 3. Grfico Burndown Sprint* 3. Entregveis Rejeitados
4. Registro de Impedimento* 4. Registro de Impedimento* 4. Solicitaes de Mudana Aprovadas
5. Cronograma de Planejamento da 5. Dono do Produto 5. Solicitaes de Mudana No
Release 6. Experincia do Dia Anterior de Trabalho Aprovadas
6. Dependncias 7. Scrumboard 6. Riscos Identificados
7. Recomendaes do Scrum Guidance 8. Dependncias 7. Backlog do Produto do Programa
Body FERRAMENTAS Atualizado
FERRAMENTAS 1. Reunio Diria* 8. Registro(s) de Retrospectiva do Sprint
1. Expertise do Time* 2. Trs Perguntas Dirias* 9. Dependncias
2. Software 3. Sala de Guerra 10. Cronograma de Planejamento da
3. Outras Ferramentas de Desenvolvimento 4. Videoconferncia Release
4. Expertise do Scrum Guidance Body 11. Recomendaes do Scrum Guidance
SADAS
Body
SADAS 1. Grfico Burndown do Sprint Atualizado*
1. Entregvel do Sprint* 2. Registro de Impedimento Atualizado* FERRAMENTAS
2. Scrumboard Atualizado* 3. Time Scrum Motivado 1. Reunies de Reviso do Backlog
3. Registro de Impedimento Atualizado* 4. Scrumboard Atualizado Priorizado do Produto*
4. Solicitaes de Mudana No Aprovadas 5. Solicitaes de Mudana No 2. Tcnicas de Comunicao
5. Riscos Identificados Aprovadas 3. Outras Tcnicas do Backlog do Produto
6. Mitigao de Riscos 6. Riscos Identificados Priorizado e Refinado
7. Dependncias Atualizadas 7. Riscos Mitigados SADAS
8. Dependncias Atualizadas 1. Backlog Priorizado do Produto
Atualizado*
2. Cronograma de Planejamento da
Release Atualizado
10

Figura 10-1: Viso Geral de Implementar

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 215


10 IMPLEMENTAR

A figura 10-2 abaixo mostra as entradas, ferramentas e sadas obrigatrias para os processos da fase de
Implementar.

10.1 Criar os Entregveis 10.2 Conduzir a Reunio Diria 10.3 Refinamento do Backlog
Priorizado do Produto
ENTRADAS ENTRADAS ENTRADAS
1. Time Central do Scrum* 1. Time Scrum* 1. Time Central do Scrum*
2. Backlog do Sprint* 2. Scrum Master* 2. Backlog Priorizado do Produto*
3. Scrumboard* 3. Grfico Burndown Sprint* FERRAMENTAS
4. Registro de Impedimento* 4. Registro de Impedimento* 1. Reunies de Reviso do Backlog
FERRAMENTAS FERRAMENTAS Priorizado do Produto*
1. Expertise do Time* 1. Reunio Diria* SADAS
SADAS 2. Trs Perguntas Dirias* 1. Backlog Priorizado do Produto
1. Entregvel do Sprint* SADAS Atualizado*
2. Scrumboard Atualizado* 1. Grfico Burndown do Sprint
3. Registro de Impedimento Atualizado* Atualizado*
2. Registro de Impedimento Atualizado*

Figura 10-2: Viso Geral de Implementar (Fundamentos)

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

216 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.1 Criar os Entregveis


A figura 10-3 abaixo mostra todas as entradas, ferramentas e sadas para do processo de Criar os
Entregveis.

1. Time Central do Scrum* 1. Expertise do Time* 1. Entregvel do Sprint*


2. Backlog do Sprint* 2. Software 2. Scrumboard Atualizado*
3. Scrumboard* 3. Outras Ferramentas de 3. Registro de Impedimento
4. Registro de Impedimento* Desenvolvimento Atualizado*
5. Cronograma de Planejamento 4. Expertise do Scrum Guidance 4. Solicitaes de Mudana No
da Release Body Aprovadas
6. Dependncias 5. Riscos Identificados
7. Recomendaes do Scrum 6. Mitigao de Riscos
Guidance Body 7. Dependncias Atualizadas

Figura 10-3: Criar EntregveisEntradas, Ferramentas, e Sadas

10

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 217


10 IMPLEMENTAR

Figura 10-4: Criar EntregveisDiagrama de Fluxo de Dados

218 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.1.1 Entradas

10.1.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

10.1.1.2 Backlog do Sprint*

Descrito na seo 9.5.3.1.

10.1.1.3 Scrumboard*

A transparncia do Scrum vem de ferramentas de informao abertamente visveis, como o Scrumboard,


que mostra o progresso do time. O time usa um Scrumboard para planejar e acompanhar seu progresso
durante cada Sprint. Contm quatro colunas para indicar o progresso das tarefas previstas para o Sprint: a
coluna Fazer (para as tarefas que ainda no foram iniciadas), a coluna Em Processo (para as tarefas que
foram iniciadas, mas que ainda no esto concludas), a coluna de Teste (para as tarefas concludas, mas
que esto no processo teste), e a coluna Pronto (para as tarefas que foram concludas e testadas com
10
sucesso). No incio de um Sprint, todas as tarefas selecionadas para aquele Sprint so colocadas na coluna
'Fazer' e posteriormente sero movidas para a coluna seguinte de acordo com o seu progresso.

Figura 10-5: Scrumboard

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 219


10 IMPLEMENTAR

O Scrumboard preferencialmente deve ser mantido manualmente, com as informaes sendo adicionadas
em papis ou diretamente em um quadro, mas tambm pode ser mantido electronicamente, em uma
planilha.

O Time Scrum deve mudar ou adicionar informaes no Scrumboard, conforme necessrio, para que o
Scrumboard fornea informao visual e controle sobre o trabalho que est sendo desenvolvido, tal como
acordado e comprometido pelo time.

10.1.1.4 Registro de Impedimento*

Um impedimento qualquer entrave ou obstculo que reduza a produtividade do Time Scrum.


Impedimentos devem ser identificados, resolvidos e removidos se o time quiser continuar a trabalhar de
forma eficaz. Impedimentos podem ser internos (ex.: fluxo de trabalho ineficiente ou falta de comunicao),
ou podem ser externos (exemplos de impedimentos externos podem incluir problemas de licena de
software ou exigncias de documentos desnecessrios). O framework Scrum, com sua transparncia
inerente, facilita a identificao rpida e fcil de impedimentos. A no identificao dos impedimentos pode
ser muito caro. Impedimentos devem ser registrados formalmente pelo Scrum Master em um Log de
Impedimento, e podem ser discutidos durante as Reunies Dirias e Reunies de Reviso do Sprint,
conforme o caso.

10.1.1.5 Cronograma de Planejamento da Release

Descrito na seo 8.6.3.1.

10.1.1.6 Dependncias

Descrito na seo 9.3.3.3.

10.1.1.7 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

No processo de Criar os Entregveis, as Recomendaes do Scrum Guidance Body podem incluir melhores
prticas para criar entregas efetivamente, incluindo mtodos preferidos para a realizao de avaliaes,
testes, documentao, etc.

220 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.1.2 Ferramentas

10.1.2.1 Expertise do Time*

Refere-se experincia coletiva dos membros do Time Scrum em entender as Estrias de Usurios e
tarefas no Backlog do Sprint, a fim de criar as entregas finais. A Expertise do Time usada para avaliar as
entradas necessrias para executar o trabalho planejado para o projeto. Este julgamento e expertise so
aplicados a todos os aspectos tcnicos e de gerenciamento do projeto durante o processo de Criar os
Entregveis. Os membros do Time Scrum tm a autoridade e a responsabilidade de determinar os
melhores meios para a converso dos Itens do Backlog Priorizado do Produto em produtos acabados, sem
a necessidade de envolvimento de nenhum stakeholder de fora do time. Expertise adicional est disponvel
no Scrum Guidance Body, conforme exigido.

10.1.2.2 Software

As ferramentas automatizadas de software podem ser usadas para agendamento, coleta de informaes e
distribuio. As ferramentas de colaborao virtual tambm so essenciais em projetos onde o Time Scrum
no est no mesmo local de trabalho. Uma variedade de ferramentas baseadas em software automatizado
esto disponveis, que permitem o acompanhamento dos progressos, coleta de dados e distribuio, e
contribuem para acelerar os processos. 10

10.1.2.3 Outras Ferramentas de Desenvolvimento

Com base nos requisitos das especificaes do projeto e da indstria, outras ferramentas de
desenvolvimento podem ser usadas em conformidade.

1. Refactoring

Refactoring uma ferramenta especfica para projetos de software. O objetivo desta tcnica o de
melhorar a manuteno do cdigo existente e torn-lo mais simples, mais conciso, e mais flexvel.
Refactoring significa melhorar o design do cdigo atual, sem alterar a forma como o cdigo se
comporta. Envolve o seguinte:

Eliminar cdigo repetitivo e redundante


Dividir mtodos e funes em rotinas menores
Definir claramente as variveis e os nomes dos mtodos
Simplificar o design do cdigo
Tornar o cdigo mais fcil de se entender e de se modificar

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 221


10 IMPLEMENTAR

Refactoring regular otimiza o design do cdigo um pouco de cada vez, ao longo de um perodo de
tempo. Em ltima anlise, os resultados de refactoring mais limpo, com cdigo mais sustentvel,
preservando todas as funcionalidades.

2. Padres de Design

Os Padres de Design fornecem uma maneira formal de registro de uma resoluo, para um
problema de design em uma rea de especializao especfica. Esses padres registram tanto o
processo usado quanto a resoluo atual, o que pode ser reutilizado mais tarde para melhorar a
tomada de deciso e produtividade.

10.1.2.4 Expertise do Scrum Guidance Body

Descrito na seo 8.4.2.7.

Nos processos de Criar os Entregveis e de Aprovar, Estimar e Comprometer as Estrias de Usurio, a


Expertise do Scrum Guidance Body pode relacionar-se com as regras e regulamentos documentados,
diretrizes de desenvolvimento; ou padres e melhores prticas (por exemplo, orientaes sobre como
realizar revises ou testes). Tambm pode haver uma time de especialistas no assunto, que podem
fornecer orientao para o Time Scrum na criao de entregas. Este time pode incluir Arquitetos,
Desenvolvedores Snior, Especialistas em Segurana, ou outras pessoas experientes.

10.1.3 Sadas

10.1.3.1 Entregvel do Sprint*

No final de cada Sprint, um incremento do produto ou um entregvel concludo. O entregvel deve


possuir todas as caractersticas e funcionalidades definidas nas Estrias de Usurio includas no Sprint e
devem ter sido testadas com sucesso.

10.1.3.2 Scrumboard Atualizado*

O Scrumboard atualizado regularmente, conforme o time conclui as tarefas. No entanto, no final do Sprint,
o Scrumboard ser reposto ou apagado e um novo Scrumboard criado para o prximo Sprint.

10.1.3.3 Registro de Impedimento Atualizado*

222 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

Descrito na seo 10.1.1.4.

10.1.3.4 Solicitaes de Mudana No Aprovadas

Descrito na seo 8.4.1.6.

10.1.3.5 Riscos Identificados

Descrito na seo 8.4.3.4.

10.1.3.6 Mitigao de Riscos

Conforme o Time Scrum executa o trabalho de criao de entregas, de acordo com as Estrias de Usurio
no Backlog do Produto, ele realiza as aes mitigadoras que foram definidas para tratar dos Riscos
Identificados previamente. Ao longo do processo de Criar os Entregveis, o time documenta quaisquer
Riscos Identificados recentemente, e as aes mitigadoras tomadas. O registro dos riscos do projeto um
documento ativo, continuamente atualizado pelo time durante todo o projeto, para refletir o status atual de
todos os riscos.

Informaes adicionais sobre o Gerenciamento de Riscos so descritas na seo 7.4.3


10

10.1.3.7 Dependncias Atualizadas

Descrito na seo 9.3.3.3.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 223


10 IMPLEMENTAR

10.2 Conduzir a Reunio Diria


A figura 10-6 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Conduzir a
Reunio Diria.

1. Time Scrum* 1. Reunio Diria* 1. Grfico Burndown do Sprint


2. Scrum Master* 2. Trs Perguntas Dirias* Atualizado*
3. Grfico Burndown Sprint* 3. Sala de Guerra 2. Registro de Impedimento
4. Registro de Impedimento* 4. Videoconferncia Atualizado*
5. Dono do Produto 3. Time Scrum Motivado
6. Experincia do Dia Anterior de 4. Scrumboard Atualizado
Trabalho 5. Solicitaes de Mudana No
7. Scrumboard Aprovadas
8. Dependncias 6. Riscos Identificados
7. Riscos Mitigados
8. Dependncias Atualizadas

Figura 10-6: Conduzir a Reunio DiriaEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

224 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

Figura 10-7: Conduzir a Reunio DiriaDiagrama de Fluxo de Dados 10

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 225


10 IMPLEMENTAR

10.2.1 Entradas

10.2.1.1 Time Scrum*

Descrito na seo 8.3.3.1.

10.2.1.2 Scrum Master*

Descrito na seo 8.2.3.1.

10.2.1.3 Grfico Burndown Sprint*

Descrito na seo 9.5.3.2.

10.2.1.4 Registro de Impedimento*

Descrito na seo 10.1.1.4.

10.2.1.5 Dono do Produto

Descrito na seo 8.1.3.1.

10.2.1.6 Experincia do Dia Anterior de Trabalho

Os membros do Time Scrum fornecem atualizaes de status para seus colegas de time durante a Reunio
Diria. Os membros permacem em p durante toda a reunio, e discutem as conquistas e experincias de
trabalho do dia anterior. Esta experincia um input importante para a Reunio Diria.

10.2.1.7 Scrumboard

Descrito na seo 10.1.1.3.

226 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.2.1.8 Dependncias

Descrito na seo 9.3.3.3.

10.2.2 Ferramentas

10.2.2.1 Reunio Diria*

A Reunio Diria uma reunio curta, Time-boxed em 15 minutos. Os membros do time se renem para
relatar o seu progresso no Sprint e para planejar as atividades do dia. A durao da reunio muito curta e
todos os membros do Time Scrum devem estar presentes. No entanto, a reunio no dever ser cancelada
ou atrasada, se um ou mais membros no estiverem presentes.

Durante a reunio, cada membro do Time Scrum fornece respostas para as Trs Perguntas Dirias,
conforme mencionado na seo 10.2.2.2. As discusses entre o Scrum Master e o time, ou entre alguns
membros do Time Scrum, so incentivadas, mas essas discusses acontecem aps a reunio para garantir
que a Reunio Diria seja curta.

10.2.2.2 Trs Perguntas Dirias* 10

Durante as Reunies Dirias, facilitadas pelo Scrum Master, cada membro do Time Scrum fornece
informaes na forma de resposta, a estas trs perguntas especficas:

O que eu fiz ontem?


O que eu vou fazer hoje?
Que impedimentos ou obstculos (se houver) estou enfrentando atualmente?

Concentrando-se nestas trs perguntas, o time inteiro pode ter uma compreenso clara sobre o status do
trabalho. Ocasionalmente, outros itens podem ser discutidos, mas isso reduzido ao mnimo, j que a
reunio Time-boxed para que os membros no percam o foco.

altamente recomendvel que as duas primeiras questes sejam respondidas pelos membros do time, se
possvel, de forma quantitativa, ao invs de respostas longas qualitativos. Aps o trmino da Reunio
Diria, os membros do time podem organizar reunies adicionais para abordar outros itens que necessitem
ser discutidos com mais detalhes.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 227


10 IMPLEMENTAR

10.2.2.3 Sala de Guerra

Em Scrum, prefervel que o time esteja localizado no mesmo ambiente de trabalho. O termo comumente
usado para descrever esse lugar conhecido como Sala de Guerra. Normalmente, esse local projetado
de tal forma, que os membros do time podem circular livremente, trabalhar e comunicar-se facilmente. Pois
esto localizados prximos um do outro. Normalmente cartes de ndice, notas e outras ferramentas de
baixa, ou alta tecnologia, so disponibilizadas nesta sala para facilitar o fluxo de trabalho, colaborao e
resoluo de problemas.

Esta sala muitas vezes barulhenta devido a conversas do time, porm essas conversas contribuem para o
progresso do time. Uma Sala de Guerra boa no deve possuir divisrias (no formato de cubculos) e deve
permite que o time sente junto para garatir a comunicao cara-a-cara. A Sala de Guerra ainda, ideal para
a realizao de Reunies Dirias.

O(s) Stakeholder(s) membros de outros Times Scrum tambm podem circular pela Sala de Guerra e discutir
questes relevantes.

10.2.2.4 Videoconferncia

Em situaes da vida real, pode ser que no seja sempre possvel ter todo o Time Scrum no mesmo local
de trabalho. Nesses casos, torna-se imperativa a utilizao de ferramentas de videoconferncia para
permitir a comunicao cara-a-cara.

10.2.3 Sadas

10.2.3.1 Grfico Burndown do Sprint Atualizado*

Descrito na seo 9.5.3.2.

10.2.3.2 Registro de Impedimento Atualizado*

Descrito na seo 10.1.1.4.

10.2.3.3 Time Scrum Motivado

As Reunies Dirias propagam a ideia de que cada membro do time importante, sendo um dos principais
contribuintes, o que melhora o moral individual e do time. Isto, juntamente com o conceito de times auto-

228 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

organizados, melhora a motivao geral, leva a um melhor desempenho do time e melhora a qualidade das
entregas produzidas.

O Time Scrum descrito na seo 8.3.3.1.

10.2.3.4 Scrumboard Atualizado

Descrito na seo 10.1.1.3.

10.2.3.5 Solicitaes de Mudana No Aprovadas

Descrito na seo 8.4.1.6.

10.2.3.6 Riscos Identificados

Descrito na seo 8.4.3.4.

10
10.2.3.7 Riscos Mitigados

Descrito na seo 10.1.3.6.

10.2.3.8 Dependncias Atualizadas

Descrito na seo 9.3.3.3.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 229


10 IMPLEMENTAR

10.3 Refinamento do Backlog Priorizado do Produto


A figura 10-8 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Refinamento do
Backlog Priorizado do Produto.

1. Time Central do Scrum* 1. Reunies de Reviso do 1. Backlog Priorizado do Produto


2. Backlog Priorizado do Produto* Backlog Priorizado do Produto* Atualizado*
3. Entregveis Rejeitados 2. Tcnicas de Comunicao 2. Cronograma de Planejamento
4. Solicitaes de Mudana 3. Outras Tcnicas do Backlog do da Release Atualizado
Aprovadas Produto Priorizado e Refinado
5. Solicitaes de Mudana No
Aprovadas
6. Riscos Identificados
7. Backlog do Produto do
Programa Atualizado
8. Registro(s) de Retrospectiva do
Sprint
9. Dependncias
10. Cronograma de Planejamento
da Release
11. Recomendaes do Scrum
Guidance Body

Figura 10-8: Refinamento do Backlog Priorizado do ProdutoEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

230 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10
Figura 10-9: Refinamento do Backlog Priorizado do ProdutoDiagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 231


10 IMPLEMENTAR

10.3.1 Entradas

10.3.1.1 Time Central do Scrum*

Descrito na seo 8.1.3.1, 8.2.3.1, and 8.3.3.1.

10.3.1.2 Backlog Priorizado do Produto*

Descrito na seo 8.5.3.1.

10.3.1.3 Entregveis Rejeitados

Nos casos em que a entrega no atender aos Critrios de Aceitao, ser considerado um Entregvel
Rejeitado. Os Entregveis Rejeitados normalmente no so mantidos em uma lista separada.
Simplesmente permanecem no Backlog Priorizado do Produto e no so classificados como Pronto, dessa
forma podero ser re-priorizados no processo de Refinamento do Backlog Priorizado do Produto e serem
considerados para serem desenvolvidos no prximo Sprint.

10.3.1.4 Solicitaes de Mudana Aprovadas

Descrito na seo 8.4.1.5.

10.3.1.5 Solicitaes de Mudana No Aprovadas

Descrito na seo 8.4.1.6.

10.3.1.6 Riscos Identificados

Descrito na seo 8.4.3.4.

232 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.3.1.7 Backlog do Produto do Programa Atualizado

Semelhante ao Backlog do Produto do Projeto, o Backlog do Produto do Programa tambm pode estar
sujeito ao refinamento peridico para incorporar novos requisitos e mudanas. As mudanas no Backlog do
Produto do Programa podem ser o resultado de condies externas ou internas. As condies externas
podem incluir a mudana de cenrio de negcio, tendncias tecnolgicas, ou requisitos de conformidade
legal. Os fatores internos que afetam o Backlog do Produto do Programa podem estar relacionados as
modificaes de estratgias ou polticas organizacionais, Riscos Identificados e outros fatores. As
Mudanas nos requisitos do Backlog do Produto do Programa, muitas vezes afetam o Backlog do Produto
do Projeto de projetos subjacentes, por isso eles devem ser levados em conta durante o processo de
Refinamento do Backlog Priorizado do Produto.

10.3.1.8 Registro(s) de Retrospectiva do Sprint

Descrito na seo 11.3.3.4.

10.3.1.9 Dependncias

Descrito na seo 9.3.3.3. 10

10.3.1.10 Cronograma de Planejamento da Release

Descrito na seo 8.6.3.1.

10.3.1.11 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

No processo de Refinamento do Backlog Priorizado do Produto, as Recomendaes do Scrum Guidance


Body podem incluir melhores prticas sobre como entender e coletar sistematicamente os requisitos dos
Stakeholders e do Times Scrum e, em seguida, priorizar corretamente o Backlog do Produto e comunicar as
atualizaes para todas as pessoas relevantes envolvidas no projeto Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 233


10 IMPLEMENTAR

10.3.2 Ferramentas

10.3.2.1 Reunies de Reviso do Backlog Priorizado do Produto*

O Dono do Produto pode ter vrias e distintas reunies com os stakeholders relevantes, Scrum Master e
Time Scrum para garantir que ele ou ela tem informaes suficientes para fazer atualizaes no Backlog
Priorizado do Produto durante o processo de Refinamento do Backlog Priorizado do Produto.

A inteno das Reunies de Reviso do Backlog Priorizado do Produto assegurar que as Estrias de
Usurio e os Critrios de Aceitao so compreendidos, e escritos corretamente pelo Dono do Produto,
para que reflitam os requisitos e prioridades reais dos stakeholders (clientes); as Estrias de Usurio so
compreendidas por todos no Time Scrum; e aquelas Estrias de Usurio de alta prioridade so bem-
refinadas para que o Time Scrum possa estimar e se comprometer corretamente com essas Estrias de
Usurio.

As Reunies de Reviso do Backlog Priorizado do Produto tambm garantem que as Estrias de Usurio
irrelevantes sejam removidas e quaisquer Solicitaes de Mudana Aprovadas ou Riscos Identificados
sejam incorporados ao Backlog Priorizado do Produto.

10.3.2.2 Tcnicas de Comunicao

O Scrum promove a comunicao precisa e eficaz, principalmente atravs de colocation do Time Scrum. O
Scrum tambm favorece interaes informais, cara-a-cara, ao invs de comunicaes formais por escrito.
Quando um Time Scrum precisa ser distribudo, o Scrum Master deve garantir que as tcnicas eficazes de
comunicao estejam disponveis para que os times possam se auto-organizar e trabalhar eficazmente.

10.3.2.3 Outras Tcnicas do Backlog do Produto Priorizado e Refinado

Alguns outras ferramentas do Backlog do Produto Priorizado e Refinado incluem muitas das mesmas
ferramentas utilizadas para os seguintes processos:

Desenvolver os pico(s)Descrito na seo 8.4.2.


Criar o Backlog Priorizado do ProdutoDescrito na seo 8.5.2.
Conduzir o Planejamento da ReleaseDescrito na seo 8.6.2.
Criar as Estrias de UsurioDescrito na seo 9.1.2.
Aprovar, Estimar e Comprometer as Estrias de UsurioDescrito na seo 9.2.2.
Criar as TarefasDescrito na seo 9.3.2.
Estimar as TarefasDescrito na seo 9.4.2.

234 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


10 IMPLEMENTAR

10.3.3 Sadas

10.3.3.1 Backlog Priorizado do Produto Atualizado*

Descrito na seo 8.5.3.1.

O Backlog Priorizado do Produto pode ser atualizado com: novas Estrias de Usurios, novas Solicitaes
de Mudana, novos Riscos Identificados, Estrias de Usurios atualizadas, ou redefinio de prioridades de
Estrias de Usurios existentes.

10.3.3.2 Cronograma de Planejamento da Release Atualizado

Descrito na seo 8.6.3.1.

O Cronograma de Planejamento da Release pode ser atualizado para refletir o impacto de Estrias de
Usurio novas ou alteradas no Backlog Priorizado do Produto.

10

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 235


10 IMPLEMENTAR

10.4 Fase do Diagrama de Fluxo de Dados

Figura 10-10: Fase de ImplementarDiagrama de Fluxo de Dados

236 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11. REVISO E RETROSPECTIVA


A fase de Reviso e Retrospectiva est preocupada com a reviso dos entregveis, com o trabalho que tem
sido feito e em determinar formas de melhorar as prticas e os mtodos utilizados na realizao do trabalho
do projeto. Em grandes organizaes, os processos de Reviso e Retrospectiva tambm podem incluir a
convocao de Reunies do Scrum de Scrums.

Reviso e Retrospectiva, conforme definido em Um Guia para o Conhecimento em Scrum (Guia SBOK),
aplicvel a:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Para facilitar a melhor aplicao do framework Scrum, este captulo identifica as entradas, ferramentas e
sadas de cada processo como "obrigatrias" ou "opcionais". As entradas, ferramentas e sadas, indicadas
por asteriscos (*), so de obrigatrias, enquanto que as sem asteriscos, so opcionais. 11

Recomenda-se que o Time Scrum e os indivduos que esto sendo introduzidos aos processos e framework
Scrum, se concentrem principalmente nas entradas, ferramentas e sadas obrigatrias; enquanto que os
Donos do Produto, Scrum Masters, e outros profissionais mais experientes em Scrum, devem esforar-se
para obter um conhecimento mais profundo da informao contida neste captulo inteiro. Tambm
importante perceber que, apesar de todos os processos serem definidos exclusivamente no Guia SBOK ,
eles no so necessariamente realizados sequencialmente ou separadamente. s vezes, pode ser mais
conveniente combinar alguns processos, dependendo dos requisitos especficos de cada projeto.

Este captulo escrito a partir da perspectiva de um Time Scrum, que est trabalhando em um Sprint, para
produzir Entregveis potencialmente utilizveis, como parte de um projeto maior. No entanto, a informao
descrita igualmente aplicvel a projetos, programas e portflios inteiros. As informaes adicionais
relativas utilizao do Scrum para projetos, programas e portflios esto disponveis do captulo 2 ao 7,
que abrangem os princpios do Scrum e os aspectos do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 237


11 REVISO E RETROSPECTIVA

A figura 11-1 fornece uma viso geral dos seguintes processos da fase de Reviso e Retrospectiva:

11.1 Convocar o Scrum de ScrumsNeste processo, os representantes do Time Scrum so convocados


para as Reunies de Scrum de Scrums (SoS) em intervalos predeterminados ou conforme necessrio, para
colaborar e acompanhar os respectivos progressos, impedimentos e as dependncias entre os times. Isso
relevante apenas em projetos grandes, onde vrios Times Scrum esto envolvidos.

11.2 Demonstrar e Validar o SprintNeste processo, o Time Scrum apresenta os Entregveis do Sprint
ao Dono do Produto e aos stakeholders relevantes em uma Reunio de Reviso do Sprint. O objetivo dessa
reunio garantir a aprovao e aceitao do Dono do Produto para produto ou servio.

11.3 Retrospectiva do Sprint Neste processo, o Scrum Master e o Time Scrum se renem para discutir
as lies aprendidas durante o Sprint. Esta informao documentada como lies aprendidas que
podero ser aplicadas em Sprints futuros. Muitas vezes, como resultado dessa reunio, podem ocorrer
Pontos de Melhoria Acordados ou Recomendaes Atualizadas do Scrum Guidance Body.

238 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.1 Convocar o Scrum de Scrums 11.2 Demonstrar e Validar o Sprint 11.3 Retrospectiva do Sprint

ENTRADAS ENTRADAS ENTRADAS


1. Scrum Master ou Representantes do 1. Time Central do Scrum* 1. Scrum Master*
Time Scrum* 2. Entregveis do Sprint* 2. Time Scrum*
2. Scrum Master Chefe 3. Backlog do Sprint* 3. Sadas de Demonstrar e Validar o
3. Dono do Produto Chefe 4. Critrio de Pronto* Sprint*
4. Agenda de Reunio 5. Critrios de Aceitao da Estria de 4. Dono do Produto
5. Registro de Impedimentos Usurio* 5. Recomendaes do Scrum Guidance
6. Dependncias 6. 6 Stakeholder(s) Body
7. Sadas da Retrospectiva do Sprint 7. Cronograma de Planejamento da FERRAMENTAS
FERRAMENTAS Release 1. Reunio de Retrospectiva do Sprint*
1. Reunio do Scrum de Scrums* 8. Riscos Identificados 2. ESVP
2. Quatro Perguntas por Time* 9. Dependncias 3. Lancha
3. Videoconferncia 10. Recomendaes do Scrum Guidance 4. Tcnicas de Medio
4. Sala de Reunies Body 5. Expertise do Scrum Guidance Body
5. Expertise do Scrum Guidance Body FERRAMENTAS SADAS
SADAS 1. Reunies de Reviso do Sprint* 1. Pontos de Melhoria Acordados*
1. Coordenao Melhor do Time* 2. Anlise de Valor Agregado 2. Itens de Ao Atribuda e Datas de
2. Problemas Resolvidos 3. Expertise do Scrum Guidance Body Vencimento
3. Registro de Impedimentos Atualizado SADAS 3. Itens No -Funcionais Propostos para o
4. Dependncias Atualizadas 1. Entregveis Aceitos* Backlog Priorizado do Produto
2. Entregveis Rejeitados 4. Registro(s) de Retrospectiva do Sprint
3. Riscos Atualizados 5. Lies Aprendidas pelo Time Scrum
4. Resultado da Anlise de Valor Agregado 6. Recomendaes Atualizadas do Scrum
5. Cronograma de Planejamento da Guidance Body
Release Atualizada
6. Dependncias Atualizadas

11
Figura 11-1: Viso Geral de Reviso e Retrospectiva

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 239


11 REVISO E RETROSPECTIVA

A figura 11-2 abaixo mostra as entradas, ferramentas e sadas obrigatrias, para os processos em fase de
Reviso e Retrospectiva.

11.1 Convocar o Scrum de 11.2 Demonstrar e Validar o 11.3 Retrospectiva do Sprint


Scrums Sprint
ENTRADAS ENTRADAS ENTRADAS
1. Scrum Master ou Representantes do 1. Time Central do Scrum* 1. Scrum Master*
Time Scrum* 2. Entregveis do Sprint* 2. Time Scrum*
FERRAMENTAS 3. Backlog do Sprint* 3. Sadas de Demonstrar e Validar o
1. Reunio do Scrum de Scrums* 4. Critrio de Pronto* Sprint*
2. Quatro Perguntas por Time* 5. Critrios de Aceitao da Estria de FERRAMENTAS
SADAS Usurio* 1. Reunio de Retrospectiva do Sprint*
1. Coordenao Melhor do Time* FERRAMENTAS SADAS
1. Reunies de Reviso do Sprint* 1. Pontos de Melhoria Acordados*
SADAS
1. Entregveis Aceitos*

Figura 11-2: Viso Geral de Reviso e Retrospectiva (Fundamentos)

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

240 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.1 Convocar o Scrum de Scrums


A figura 11-3 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Convocar o Scrum
de Scrums.

1. Scrum Master ou Representantes 1. Reunio do Scrum de Scrums* 1. Coordenao Melhor do Time*


do Time Scrum* 2. Quatro Perguntas por Time* 2. Problemas Resolvidos
2. Scrum Master Chefe 3. Videoconferncia 3. Registro de Impedimentos
3. Dono do Produto Chefe 4. Sala de Reunies Atualizado
4. Agenda de Reunio 5. Expertise do Scrum Guidance 4. Dependncias Atualizadas
5. Registro de Impedimentos Body
6. Dependncias
7. Sadas da Retrospectiva do
Sprint

Figura 11-3: Convocar o Scrum de ScrumsEntradas, Ferramentas, e Sadas

11

Figura 11-4: Convocar o Scrum de ScrumsDiagrama de Fluxo de Dados

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 241


11 REVISO E RETROSPECTIVA

11.1.1 Entradas

11.1.1.1 Scrum Master ou Representantes do Time Scrum*

Normalmente, um membro de cada Time Scrum ir representar o seu time na Reunio do Scrum de
Scrums (SoS). Na maioria dos casos o Scrum Master ser este representante, mas s vezes outros
membros tambm podem desempenhar este papel. Uma nica pessoa pode ser nomeada pelo time para
represent-los em todas as Reunies do SoS, ou o representante pode mudar ao longo do tempo, com
base em quem pode desempenhar melhor este papel, de acordo com os problemas e circunstncias atuais.
Cada pessoa envolvida na reunio deve ter o conhecimento tcnico, para ser capaz de identificar os casos
em que os times podem causar impedimentos ou atrasos uns aos outros.

11.1.1.2 Scrum Master Chefe

Descrito na seo 8.2.1.6.

11.1.1.3 Dono(s) do Produto Chefe(s)

Descrito na seo 8.1.1.5

11.1.1.4 Agenda de Reunio

O principal objetivo da Reunio do Scrum de Scrums (SoS) comunicar o progresso entre vrios times. O
Scrum Master Chefe (ou qualquer Scrum Master que facilite a Reunio do SoS) pode anunciar uma agenda
antes da reunio. Isso permite que os times individualmente considerem os itens da agenda, e se preparem
para a Reunio do SoS. Quaisquer obstculos sendo enfrentados pelo time, que possam tambm afetar
outros times, devem ser indicados para que sejam informados durante a Reunio do SoS. Alm disso, se
um time tomar conhecimento de um problema, mudana ou risco de grande escala, que pode afetar outros
times, o mesmo deve ser comunicado na Reunio do SoS.

11.1.1.5 Registro de Impedimentos

Descrito na seo 10.1.1.4.

242 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.1.1.6 Dependncias

Descrito na seo 9.3.3.3.

11.1.1.7 As Sadas da Retrospectiva do Sprint

As sadas do processo de Retrospectiva do Sprint podem ter problemas que poderiam impactar vrios
Times Scrum, e poderiam ser usados como input para uma Reunio do Scrum de Scrums (SOS) eficaz.

11.1.2 Ferramentas

11.1.2.1 Reunio do Scrum de Scrums*

So reunies preferencialmente curtas (normalmente no so Time-boxed para permitir um


compartilhamento de informaes maior entre os times), onde um representante de cada Time Scrum se
rene para compartilhar os status de seus respectivos times. A Reunio do Scrum de Scrums (SoS)
realizada em intervalos predeterminados, ou quando exigido pelos Times Scrum, para facilitar o
compartilhamento de informaes entre os diferentes Times Scrum. Os problemas, dependncias e riscos 11
que impactam vrios Times Scrum podem ser acompanhados de perto, o que ajuda os vrios times que
trabalham em um projeto grande, a coordenar e integrar de uma maneira melhor os seus trabalhos. O
Scrrum Master Chefe (ou outro Scrum Master que facilite as Reunies do SoS) responsvel em garantir
que todos os representantes tenham um ambiente propcio ao compartilhamento de informaes, de uma
maneira honesta e aberta, incluindo o feedback para outros representantes do time. Para projetos maiores,
envolvendo um nmero significante de times, podero ser convocados vrios nveis dessas reunies, para
compartilhar o status dos respectivos times.

A Reunio do SoS descrita detalhadamente na seo 3.7.2.

11.1.2.2 Quatro Perguntas por Time*

Cada representante do Time Scrum ir fornecer atualizaes de seu time, sucessivamente. Essas
atualizaes so normalmente fornecidas sob a forma de respostas a quatro perguntas especficas:

1) No que o meu time tem trabalhado desde a ltima reunio?


2) O que o meu time vai fazer at a prxima reunio?
3) O que os outros times estavam esperando o nosso time concluir que ainda no foi feito?
4) O que o nosso time est planejando fazer que poder afetar os outros times?

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 243


11 REVISO E RETROSPECTIVA

As respostas a estas quatro perguntas, fornecem informaes que permitem que cada time entenda
claramente o status de trabalho de todos os outros times.

11.1.2.3 Videoconferncia

Descrito na seo 10.2.2.4

muito provvel que a Reunio do Scrum de Scrums (SoS) no seja cara-a-cara. A videoconferncia
normalmente necessria em projetos grandes, onde h uma maior possibilidade de haverem times em
diferentes locais de trabalho.

11.1.2.4 Sala de Reunies

Recomenda-se que uma sala de conferncias seja disponibilizada para a Reunio do SoS, onde todos os
representantes do Time Scrum possam estar confortveis.

11.1.2.5 Expertise do Scrum Guidance Body

Tambm descrito na seo 8.4.2.7.

No processo de Convocar o Scrum de Scrums, a Expertise do Scrum Guidance Body pode relacionar-se
com as melhores prticas documentadas, sobre como conduzir as Reunies do Scrum de Scrums (SoS), e
como incorporar as sugestes de tais reunies, no trabalho do projeto de Times Scrum individuais. Tambm
pode haver um time de especialistas no assunto, que podem ajudar o Scrum Master Chefe a facilitar a
Reunio do SoS.

11.1.3 Sadas

11.1.3.1 A Coordenao Melhor do Time*

A reunio do Scrum de Scrums facilita a coordenao do trabalho entre vrios Times Scrum. Isso
especialmente importante quando h tarefas que envolvem dependncias inter-times. As incompatibilidades
e discrepncias entre o trabalho e as entregas de diferentes times so rapidamente expostas. Esse frum
tambm oferece aos times a oportunidade de demonstrar suas realizaes e de dar feedback para outros
times. Ocorre uma colaborao em toda a organizao ao se utilizar a Reunio do SoS, em oposio a
pessoas que trabalham em times fechados, preocupados primeiramente com suas responsabilidades
individuais.

244 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.1.3.2 Problemas Resolvidos

A Reunio do Scrum de Scrums (SoS) um frum onde os membros do Time Scrum, tm a oportunidade
de discutir de forma transparente, problemas que afetam seu projeto. A necessidade de entregar todos os
Sprint em tempo, obriga os times a enfrentarem ativamente esses problemas mais cedo, ao invs de adiar a
busca por resoluo. Essa oportunidade contnua de discusso e resoluo de problemas durante a
Reunio do Scrum de Scrums, melhora muito a coordenao entre os diferentes Times Scrum e tambm
reduz a necessidade de redesign e retrabalho. Os riscos relacionados s dependncias e aos prazos de
entrega tambm so mitigados.

A Reunio do SoS descrita detalhadamente na seo 3.7.2.1.

11.1.3.3 Registro de Impedimentos Atualizado

Descrito na seo 10.1.3.3.

11.1.3.4 Dependncias Atualizadas

Descrito na seo 9.3.3.3.

11

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 245


11 REVISO E RETROSPECTIVA

11.2 Demonstrar e Validar o Sprint


A figura 11-5 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Demonstrar e
Validar o Sprint.

1. Time Central do Scrum* 1. Reunies de Reviso do Sprint* 1. Entregveis Aceitos*


2. Entregveis do Sprint* 2. Anlise de Valor Agregado 2. Entregveis Rejeitados
3. Backlog do Sprint* 3. Expertise do Scrum Guidance 3. Riscos Atualizados
4. Critrio de Pronto* Body 4. Resultado da Anlise de Valor
5. Critrios de Aceitao da Estria Agregado
de Usurio* 5. Cronograma de Planejamento da
6. Stakeholder(s) Release Atualizada
7. Cronograma de Planejamento da 6. Dependncias Atualizadas
Release
8. Riscos Identificados
9. Dependncias
10. Recomendaes do Scrum
Guidance Body

Figura 11-5: Demonstrar e Validar o SprintEntradas, Ferramentas, e Sadas

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

246 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11

Figura 11-6: Demonstrar e Validar o SprintDiagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 247


11 REVISO E RETROSPECTIVA

11.2.1 Entradas

11.2.1.1 Time Central do Scrum*

Descrito na seo 8.4.1.1.

11.2.1.2 Entregveis do Sprint *

Descrito na seo 10.1.3.1

11.2.1.3 Backlog do Sprint*

Descrito na seo 9.5.3.1.

11.2.1.4 Critrio de Pronto*

Descrito na seo 8.5.3.2.

11.2.1.5 Critrios de Aceitao da Estria de Usurio*

Descrito na seo 9.4.1.3.

11.2.1.6 Stakeholder(s)

Descrito na seo 8.2.3.2.

11.2.1.7 Cronograma de Planejamento da Release

Descrito na seo 8.6.3.1.

11.2.1.8 Riscos Identificados

Descrito na seo 8.4.3.4.

248 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.2.1.9 Dependncias

Descrito na seo 9.3.3.3

11.2.1.10 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12

No processo de Demonstrar e Validar o Sprint, as Recomendaes do Scrum Guidance Body podem incluir
melhores prticas sobre como conduzir Reunies de Reviso do Sprint e avaliar os resultados da Anlise
de Valor Agregado. Alm disso, podem haver orientaes sobre como compartilhar experincias com outras
pessoas do Time Central do Scrum, e tambm com outros Times Scrum do projeto.

11.2.2 Ferramentas

11.2.2.1 Reunies de Reviso do Sprint*

Os membros do Time Central do Scrum e o(s) Stakeholder(s) relevantes(s) participam das Reunies de
Reviso do Sprint, para aceitar os entregveis que satisfaam os Critrios de Aceitao da Estria de
Usurio, e para rejeitar os entregveis inaceitveis. Essas reunies so convocadas no final de cada Sprint. 11
O Time Scrum demonstra as conquistas do Sprint, incluindo as novas funcionalidades ou produtos criados.
Isso fornece uma oportunidade ao Dono do Produto e Stakeholder(s), para inspecionar o que foi concludo
at o momento, e para determinar se as modificaes devem ser feitas no projeto ou em processos de
Sprints subsequentes.

11.2.2.2 Anlise de Valor Agregado

Descrito na seo 4.6.1

11.2.2.3 Expertise do Scrum Guidance Body

Descrito na seo 8.4.2.7.

No processo de Demonstrar e Validar o Sprint, a Expertise do Scrum Guidance Body pode relacionar-se
com as melhores prticas documentadas, sobre como conduzir as Reunies de Reviso do Sprint. Tambm
podem haver alguns especialistas que possam ajudar a fornecer orientaes, sobre a melhor forma de
facilitar uma Reunio de Reviso do Sprint.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 249


11 REVISO E RETROSPECTIVA

11.2.3 Sadas

11.2.3.1 Entregveis Aceitos*

Os entregveis finais que satisfaam os Critrios de Aceitao da Estria de Usurio so aceitos pelo Dono
do Produto. O objetivo de um Sprint criar entregveis potencialmente utilizveis, ou incrementos de
produtos, que satisfaam os Critrios de Aceitao definidos pelo cliente e pelo Dono do Produto. So
considerados Entregveis Aceitos os que podem ser liberados para o cliente, se assim o desejarem. Aps
cada Reunio de Reviso do Sprint, uma lista de Entregveis Aceitos mantida e atualizada. Se um
entregvel no cumprir os Critrios de Aceitao definidos, no ser considerado aceito e, geralmente, ser
transferido para um Sprint subsequente, para a correo de quaisquer problemas. Isso altamente
indesejvel, porque o objetivo de cada Sprint de que os entregveis satisfaam os Critrios de Aceitao.

11.2.3.2 Entregveis Rejeitados

Se os Entregveis no atenderem aos Critrios de Aceitao, os mesmos sero rejeitados. As Estrias de


Usurio associadas a estes entregveis sero adicionadas ao Backlog Priorizado do Produto, de modo que
tais entregveis possam ser considerados como parte de um Sprint posterior.

11.2.3.3 Riscos Atualizados

Descrito na seo 8.4.3.4.

11.2.3.4 Resultado da Anlise de Valor Agregado

Descrito na seo 4.6.1.

11.2.3.5 Cronograma de Planejamento da Release Atualizada

Descrito na seo 10.3.3.2.

11.2.3.6 Dependncias Atualizadas

Descrito na seo 9.3.3.3.

250 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.3 Retrospectiva do Sprint


A figura 11-7 abaixo mostra todas as entradas, ferramentas e sadas para o processo de Retrospectiva do
Sprint.

1. Scrum Master* 1. Reunio de Retrospectiva do 1. Pontos de Melhoria Acordados*


2. Time Scrum* Sprint* 2. Itens de Ao Atribuda e Datas
3. Sadas de Demonstrar e Validar o 2. ESVP de Vencimento
Sprint* 3. Lancha 3. Itens No Funcionais Propostos
4. Dono do Produto 4. Tcnicas de Medio para o Backlog Priorizado do
5. Recomendaes do Scrum 5. Expertise do Scrum Guidance Produto
Guidance Body Body 4. Registro(s) de Retrospectiva do
Sprint
5. Lies Aprendidas pelo Time
Scrum
6. Recomendaes Atualizadas do
Scrum Guidance Body

Figura 11-7: Retrospectiva do SprintEntradas, Ferramentas, e Sadas


11

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 251


11 REVISO E RETROSPECTIVA

Figura 11-8: Retrospectiva do SprintDiagrama de Fluxo de Dados

252 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.3.1 Entradas

11.3.1.1 Scrum Master*

Descrito na seo 8.2.3.1.

11.3.1.2 Time Scrum*

Descrito na seo 8.3.3.1.

11.3.1.3 Sadas de Demonstrar e Validar o Sprint*

Descrito na seo 11.2.3.

As sadas do processo de Demonstrar e Validar o Sprint fornecem informaes valiosas durante a


realizao do processo de Retrospectiva do Sprint.

11.3.1.4 Dono do Produto


11
Descrito na seo 8.1.3.1.

11.3.1.5 Recomendaes do Scrum Guidance Body

O Scrum Guidance Body pode fornecer diretrizes para a realizao de Reunies de Retrospectiva do Sprint,
incluindo sugestes de ferramentas a serem utilizadas, documentao, ou os resultados esperados das
reunies.

11.3.2 Ferramentas

11.3.2.1 Reunio de Retrospectiva do Sprint*

A Reunio de Retrospectiva do Sprint um elemento importante do framework Scrum em 'inspecionar-


adaptar', e a etapa final de um Sprint. Todos os membros do Time Scrum participam da reunio, que
facilitada ou moderada pelo Scrum Master. recomendada, mas no necessria, a participao do Dono
do Produto. Um membro do time atua como o escrivo, e documenta as discusses e os itens para ao

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 253


11 REVISO E RETROSPECTIVA

futura. essencial realizar esta reunio em um ambiente aberto e descontrado para incentivar a plena
participao de todos os membros do time. As discusses durante a Reunio de Retrospectiva do Sprint,
abrangem tanto o que deu errado, como o que deu certo. O objetivo principal da reunio identificar trs
itens especficos:

1) As coisas que o time precisa continuar fazendo: melhores prticas


2) As coisas que o time precisa comear a fazer: melhorias de processo
3) As coisas que o time precisa parar de fazer: problemas do processo e gargalos

Estas reas so discutidas, e criada uma lista de Pontos de Melhorias Acordados.

11.3.2.2 ExplorerShopperVacationerPrisoner (ESVP)

Este um exerccio que pode ser realizado no incio da Reunio de Retrospectiva do Sprint para entender a
mentalidade dos participantes e definir a direo da reunio. Os participantes so convidados a indicar
anonimamente o que melhor representa sua viso na reunio.

ExplorerQuer participar e aprender de tudo o que foi discutido na retrospectiva


ShopperQuer ouvir tudo e escolher o que ele pode tirar da retrospectiva
VacationerQuer relaxar e ser um turista na retrospectiva
PrisonerQuer estar em outro lugar e est participando da retrospectiva, porque necessrio

O Scrum Master em seguida, coleta as respostas, prepara, e compartilha a informao com o grupo.

11.3.2.3 Lancha

A Lancha uma tcnica que pode ser usada para realizar a Reunio de Retrospectiva do Sprint. Os
membros do time desempenham o papel da tripulao de uma Lancha. O barco deve chegar a uma ilha,
que simbolicamente a Viso do Projeto. Post-its so usados pelos participantes para indicar motores e
ncoras. Os motores so as coisas que os ajudam a chegar ilha, enquanto ncoras so as coisas que
esto impedindo-os de chegar ilha. Este exerccio time-boxed em alguns minutos. Uma vez que todos
os itens so documentados, a informao coletada, discutida e priorizada por meio de um processo de
votao. Com base na prioridade, os motores so reconhecidos, e aes de mitigao so planejadas para
as ncoras.

11.3.2.4 Tcnicas de Medio

Vrias medidas podem ser usadas para medir e contrastar o desempenho do time no Sprint atual, com o
seu desempenho em Sprints anteriores. Alguns exemplos incluem:

A velocidade do timeO nmero de pontos da estria concludos em um determinado Sprint.

254 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

A taxa de sucesso de ProntoA porcentagem de pontos da estria que esto Prontos versus a
porcentagem daqueles que foram prometidos.
A eficcia da estimativaO nmero ou a porcentagem de desvios entre o tempo estimado e o
tempo gasto em Tarefas e Estrias de Usurio.
A reviso das classificaes de feedbackO feedback pode ser solicitado pelo(s) Stakeholder(s),
utilizando-se as classificaes quantitativas ou qualitativas, fornecendo uma ferramenta para medir
o desempenho do time.
As classificaes da moral do timeOs resultados da auto-avaliao da moral realizada pelos
membros do time.
O feedback dos membros do timeO mecanismo de feedback de 360 graus pode ser usado para
solicitar uma crtica construtiva e insights sobre o desempenho do time.
O progresso para liberar ou lanar O valor de negcio disponveis em cada release, bem como o
valor representado pelo progresso atual relativo a uma release. Isso contribui para a motivao do
time e com o nvel de satisfao no trabalho.

11.3.2.5 Expertise do Scrum Guidance Body

Tambm descrito na seo 8.4.2.7.

No processo de Retrospectiva do Sprint, a Expertise do Scrum Guidance Body pode se relacionar com as
melhores prticas, sobre como conduzir as Reunies de Retrospectiva do Sprint. Tambm podem haver
11
alguns especialistas que possam ajudar a fornecer diretrizes, sobre como utilizar as ferramentas no
processo de Retrospectiva do Sprint, para entregar Pontos de Melhorias Acordados para os prximos
Sprints.

11.3.3 Sadas

11.3.3.1 Pontos de Melhoria Acordados*

Os Pontos de Melhoria Acordados so as sadas primrias do processo de Retrospectiva do Sprint. Uma


lista de itens de aes que criada pelo time para direcionar os problemas e melhorar os processos, com a
finalidade de aprimorar o seu desempenho em Sprints futuros.

11.3.3.2 Itens de Ao Atribuda e Datas de Vencimento

Uma vez que os Pontos de Melhoria Acordados tenham sido elaboradas e refinadas, itens de ao para
implementar as melhorias podem ser considerados pelo Time Scrum. Cada item de ao ter uma data de
vencimento definida para sua concluso.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 255


11 REVISO E RETROSPECTIVA

11.3.3.3 Itens No Funcionais Propostos para o Backlog Priorizado do Produto

Quando o Backlog Priorizado do Produto inicialmente desenvolvido, baseado em Estrias de Usurios e


funcionalidades requeridas. Frequentemente, itens no-funcionais podem no ser totalmente definidos nas
fases iniciais do projeto e podem surgir durante as Reunies de Reviso da Sprint ou de Retrospectiva da
Sprint. Esses itens devem ser adicionados ao Backlog Priorizado do Produto assim que forem descobertos.
Alguns exemplos de requisitos no-funcionais so: os prazos de resposta, as limitaes de capacidade e as
questes relacionadas com a segurana.

11.3.3.4 Registro(s) de Retrospectiva do Sprint

O Registro de Retrospectiva do Sprint um registro das opinies, discusses e de itens acionveis


apontados durante uma Reunio de Retrospectiva do Sprint. O Scrum Master pode facilitar a criao deste
registro com a colaborao de membros do Time Central do Scrum. A coleo de todos os Registros de
Retrospectiva do Sprint tornam-se o dirio do projeto, onde so detalhados os sucessos, problemas e
resolues do projeto. Os registros so documentos pblicos, disponveis para qualquer pessoa na
organizao.

11.3.3.5 Lies Aprendidas pelo Time Scrum

Espera-se que o Time Scrum auto-organizado e empoderado, aprenda com os erros cometidos durante o
Sprint. Estas lies aprendidas ajudam os times a melhorar o seu desempenho nos prximos Sprints. Estas
lies aprendidas tambm podero ser documentadas nas Recomendaes do Scrum Guidance Body, para
serem compartilhadas com outros Times Scrum.

Podem haver vrias lies positivas aprendidas como parte de um Sprint. Estas lies so a parte
fundamental da retrospectiva, e devem ser devidamente compartilhadas entre os membros do time e com o
Scrum Guidance Body, j que os times buscam o auto-aperfeioamento contnuo.

11.3.3.6 Recomendaes Atualizadas do Scrum Guidance Body

Como resultado de uma Reunio de Retrospectiva do Sprint, sugestes podem ser feitas para rever ou
melhorar as Recomendaes do Scrum Guidance Body . Se o Guidance Body aceitar estas sugestes, as
mesmas sero incorporadas como atualizaes na documentao do Scrum Guidance Body.

256 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


11 REVISO E RETROSPECTIVA

11.4 Fase do Diagrama de Fluxo de Dados

11

Figura 11-9: Fase de Reviso e RetrospectivaDiagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 257


11 REVISO E RETROSPECTIVA

258 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


12 RELEASE

12. RELEASE
A fase de release enfatiza a entrega dos Entregveis Aceitos para o cliente, e a identificao,
documentao e internalizao das lies aprendidas durante o projeto.

A Release, conforme definido em Um Guia para o Conhecimento em Scrum (Guia SBOK), aplicvel a:

Portflio, programas e/ou projetos em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders
Projetos de qualquer tamanho ou complexidade

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum pode ser aplicado efetivamente em qualquer projeto, em qualquer indstria, desde projetos
pequenos com um time de apenas seis membros ou mais, como tambm em projetos grandes e
complexos, com centenas de membros por time.

Para facilitar a melhor aplicao do framework Scrum, este captulo identifica as entradas, ferramentas e
sadas de cada processo como "obrigatrias" ou "opcionais". As entradas, ferramentas e sadas, indicadas
por asteriscos (*), so de obrigatrias, enquanto que as sem asteriscos, so opcionais.

Recomenda-se que o Time Scrum e os indivduos que esto sendo introduzidos aos processos e framework
Scrum, se concentrem principalmente nas entradas, ferramentas e sadas obrigatrias; enquanto que os
Donos do Produto, Scrum Masters, e outros profissionais mais experientes em Scrum, devem se esforam
para obter um conhecimento mais profundo da informao contida neste captulo inteiro. Tambm
importante perceber que, apesar de todos os processos serem definidos exclusivamente no Guia SBOK , 12
eles no so necessariamente realizados sequencialmente ou separadamente. As vezes, pode ser mais
conveniente combinar alguns processos, dependendo dos requisitos especficos de cada projeto.

Este captulo escrito a partir da perspectiva de um Time Scrum, que est trabalhando em um Sprint, para
produzir Entregveis potencialmente utilizveis, como parte de um projeto maior. No entanto, a informao
descrita igualmente aplicvel a projetos, programas e portflios inteiros. As informaes adicionais
relativas utilizao do Scrum para projetos, programas e portflios esto disponveis do captulo 2 ao 7,
que abrangem os princpios do Scrum e os aspectos do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 259


12 RELEASE

A figura 12-1 fornece uma viso geral dos processos em fase de Release, que so os seguintes:

12.1 Envio de Entregveis Nesse processo, Entregveis Aceitos esto em transio ou so entregues
ao Stakeholders em questo. Um Acordo de Entregveis em Funcionamento, documenta a concluso bem-
sucedida do Sprint.

12.2 Retrospectiva do ProjetoNeste processo, que finaliza o projeto, os stakeholders organizacionais e


os membros do Time Central do Scrum renem-se para fazer a Retrospectiva do Projeto e identificar,
documentar e internalizar as lies aprendidas. Muitas vezes, essas lies geram a documentao do
Acordo de Oportunidade de Melhorias, a serem implementadas em projetos futuros.

12.1 Envio de Entregveis 12.2 Retrospectiva do Projeto

ENTRADAS ENTRADAS
1. Dono do Produto* 1. Time(s) Central(is) do Scrum*
2. Stakeholder(s)* 2. Scrum Master Chefe
3. Entregveis Aceitos* 3. Dono do Produto Chefe
4. Cronograma de Planejamento da 4. Stakeholder(s)
Release* 5. Recomendaes do Scrum Guidance
5. Scrum Master Body
6. Time Scrum FERRAMENTAS
7. Critrios de Aceitao da Estria de 1. Reunio de Retrospectiva do Projeto*
Usurio 2. Outras Ferramentas para a
8. Plano Piloto Retrospectiva do Projeto
9. Recomendaes do Scrum Guidance 3. Expertise do Scrum Guidance Body
Body
SADAS
FERRAMENTAS 1. Pontos de Melhoria Acordados*
1. Mtodos de Implantao Organizacional* 2. Itens de Ao Atribuda e Datas de
2. Plano de Comunicao Vencimento*
SADAS 3. Itens No Funcionais Propostos para o
1. Contrato de Prestao de Trabalho* Backlog do Produto do Programa e para
2. Entregveis em Funcionamento o Backlog Priorizado do Produto
3. Releases do Produto 4. Recomendaes Atualizadas do Scrum
Guidance Body

Figura 12-1: Viso Geral da Release

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

260 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


12 RELEASE

A figura 12-2 abaixo, mostra as entradas, ferramentas e sadas obrigatrias para os processos em fase da
Release.

12.1 Envio de Entregveis 12.2 Retrospectiva do Projeto

ENTRADAS ENTRADAS
1. Dono do Produto* 1. Time(s) Central(is) do Scrum*
2. Stakeholder(s)* FERRAMENTAS
3. Entregveis Aceitos* 1. Reunio de Retrospectiva do Projeto*
4. Cronograma de Planejamento da SADAS
Release* 1. Pontos de Melhoria Acordados*
FERRAMENTAS 2. Itens de Ao Atribuda e Datas de
1. Mtodos de Implantao Organizacional* Vencimento*
SADAS
1. Contrato de Prestao de Trabalho*

Figura 12-2: Viso Geral da Release (Fundamentos)

12

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 261


12 RELEASE

12.1 Envio de Entregveis


A figura 12-3 mostra todas as entradas, ferramentas e sadas para o processo de Envio de Entregveis.

1. Dono do Produto* 1. Mtodos de Implantao 1. Contrato de Prestao de Trabalho*


2. Stakeholder(s)* Organizacional* 2. Entregveis em Funcionamento
3. Entregveis Aceitos* 2. Plano de Comunicao 3. Releases do Produto
4. Cronograma de Planejamento da
Release*
5. Scrum Master
6. Time Scrum
7. Critrios de Aceitao da Estria
de Usurio
8. Plano Piloto
9. Recomendaes do Scrum
Guidance Body

Figura 12-3: Envio de EntregveisEntradas, Ferramentas, e Sadas

Figura 12-4: Envio de EntregveisDiagrama de Fluxo de Dados


Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

262 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


12 RELEASE

12.1.1 Entradas

12.1.1.1 Dono do Produto*

Descrito na seo 8.1.3.1.

12.1.1.2 Stakeholder(s)*

Descrito na seo 8.2.3.2.

12.1.1.3 Entregveis Aceitos*

Descrito na seo 11.2.3.1.

12.1.1.4 Cronograma de Planejamento da Release

Descrito na seo 8.6.3.1.

12.1.1.5 Scrum Master


12
Descrito na seo 8.2.3.1.

12.1.1.6 Time Scrum

Descrito na seo 8.3.3.1.

12.1.1.7 Critrios de Aceitao da Estria de Usurio

Descrito na seo 9.1.3.2.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 263


12 RELEASE

12.1.1.8 Plano Piloto

O Plano Piloto uma entrada opcional que pode ser usada para mapear em detalhe uma implantao
piloto. O escopo e os objetivos da implantao, o usurio-base alvo da implantao, um cronograma de
implantao, os planos de transio, preparao necessria do usurio, critrios de avaliao para a
implantao, e outros elementos-chave relacionados com a implantao so especificadas no Plano Piloto
e compartilhado com os stakeholders.

12.1.1.9 Recomendaes do Scrum Guidance Body

Descrito na seo 8.1.1.12.

No processo de Envio de Entregveis, o Scrum Guidance Body pode fornecer recomendaes e


orientaes sobre a implantao de produtos. Estas so as melhores prticas que devem ser consideradas
durante a implantao de um produto para o cliente, a fim de maximizar o valor entregue.

12.1.2 Ferramentas

12.1.2.1 Mtodos de Implantao Organizacional*

Os mecanismos de implantao de cada organizao tendem a serem diferentes com base na indstria,
nos usurios-alvo e no posicionamento. Dependendo do produto a ser entregue, a implantao pode
ocorrer remotamente ou pode envolver o transporte fsico ou de transio de um item. Pelo fato de que a
implantao tende a envolver um alto nvel de risco, as organizaes normalmente tm mecanismos de
implantao bem definidos e estabelecidos, com processos detalhados, para garantir a conformidade com
todas as normas aplicveis e medidas de garantia de qualidade. Estes mecanismos podem incluir
assinaturas de concluso, de especficos representantes de gerenciamento, mecanismos de aprovao do
usurio, e orientaes sobre funcionalidades mnimas para um lanamento.

12.1.2.2 Plano de Comunicao

Em muitos projetos, existe um Plano de Comunicao. Esse plano especifica os registros que devem ser
criados e mantidos durante todo o projeto. Uma variedade de mtodos so utilizados para transmitir
informaes importantes do projeto aos stakeholders. O Plano de Comunicao define esses mtodos, bem
como quem responsvel pelas vrias atividades de comunicao. Assim que os Entregveis so testados,
o status das atividades de teste comunicado de acordo com o Plano de Comunicao, conforme
determinado pelo Dono do Produto e pelo patrocinador. Um mecanismo de comunicao comum a

264 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


12 RELEASE

exibio visual, que descreve informaes importantes em um formato fcil de se interpretar, postado em
um local acessvel, e sendo mantido atualizado com as informaes mais atuais.

12.1.3 Sadas

12.1.3.1 Contrato de Prestao de Trabalho*

Os Entregveis que atendam os Critrios de Aceitao recebem formalmente a assinatura de concluso de


negcio e a aprovao pelo cliente ou patrocinador. O reconhecimento da receita fundamental para se
obter a aceitao formal do cliente, e a responsabilidade por esta obteno ser definida pelas polticas da
empresa, no sendo necessariamente uma responsabilidade do Dono do Produto.

12.1.3.2 Entregveis em Funcionamento

Esta sada o envio final do entregvel para o qual o projeto foi sancionado. Assim que os novos
incrementos do produto so criados, os mesmos so continuamente integrados aos incrementos anteriores,
para que haja um produto disponvel potencialmente utilizvel em todos os momentos, ao longo do projeto.

12.1.3.3 Releases do Produto

As Releases do Produto devem incluir:

Contedo da ReleaseEste composto por informaes essenciais sobre os entregveis, que 12


podem ajudar o Time de Suporte ao Cliente.
Notas da ReleaseNotas de liberao devem incluir critrios de envio externos ou voltados ao
mercado para o produto a ser entregue.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 265


12 RELEASE

12.2 Retrospectiva do Projeto


A figura 12-5 mostra todas as entradas, ferramentas e sadas para o processo de Retrospectiva do Projeto.

1. Time(s) Central(s) do Scrum* 1. Reunio de Retrospectiva do 1. Pontos de Melhoria Acordados*


2. Scrum Master Chefe Projeto* 2. Itens de Ao Atribuda e Datas
3. Chief Product Owner 2. Outras Ferramentas para a de Vencimento*
4. Stakeholder(s) Retrospectiva do Projeto 3. Itens No Funcionais Propostos
5. Recomendaes do Scrum 3. Expertise do Scrum Guidance para o Backlog do Produto do
Guidance Body Body Programa e para o Backlog
Priorizado do Produto
4. Recomendaes Atualizadas do
Scrum Guidance Body

Figura 12-5: Retrospectiva do ProjetoEntradas, Ferramentas, e Sada

Figura 12-6: Retrospectiva do ProjetoDiagrama de Fluxo de Dados

Nota: Os asteriscos (*) denotam uma entrada, ferramenta ou sada "obrigatria", para o processo correspondente.

266 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


12 RELEASE

12.2.1 Entradas

12.2.1.1 Time(s) Central(is) do Scrum*

Descrito na seo 8.4.1.1.

12.2.1.2 Scrum Master Chefe

Descrito na seo 8.2.1.6.

12.2.1.3 Dono do Produto Chefe

Descrito na seo 8.1.1.5.

12.2.1.4 Stakeholder(s)

Descrito na seo 8.2.3.2.

12.2.1.5 Recomendaes do Scrum Guidance Body


12
Descrito na seo 8.1.1.12.

No processo de Retrospectiva do Projeto, as Recomendaes do Scrum Guidance Body podem incluir um


depsito de modelos internos que suportam os projetos futuros e fornecem orientao para a realizao da
Reunio de Retrospectiva do Projeto. A orientao fornecida pode relacionar-se com os procedimentos
administrativos, auditorias, avaliaes e critrios de transio do projeto. Muitas vezes, tambm incluem
como a organizao ir manter a base de conhecimento de lies aprendidas e informaes de todos os
projetos.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 267


12 RELEASE

12.2.2 Ferramentas

12.2.2.1 Reunio de Retrospectiva do Projeto*

A Reunio Retrospectiva do Projeto uma reunio para determinar as formas em que a colaborao e
eficcia do time podem ser melhoradas em projetos futuros. As oportunidades de melhorias positivas,
negativas e potenciais, tambm so discutidas. Esta reunio no Time-boxed e pode ser realizada
pessoal ou virtualmente. Incluem os seguintes participantes: Time do Projeto, Scrum Master Chefe , Dono
do Produto Chefe, e Stakeholder(s). Durante a reunio, as lies aprendidas so documentadas e os
participantes procuram por oportunidades para melhorar os processos e direcionam ineficincias.

12.2.2.2 Outras Ferramentas para a Retrospectiva do Projeto

Algumas das Ferramentas utilizadas no processo de Retrospectiva do Sprint tambm podem ser utilizadas
neste processo. Exemplos:

Exerccio de ExplorerShopperVacationerPrisoner (ESVP)


Lancha
Tcnicas de Medio

12.2.2.3 Expertise do Scrum Guidance Body

Descrito na seo 8.4.2.7.

No processo de Retrospectiva do Projeto, a principal responsabilidade do Scrum Guidance Body garantir


que as lies aprendidas em cada projeto no sejam perdidas, e sim incorporadas na organizao.

Alm disso, um rgo de orientao pode proporcionar conhecimentos especializados em vrias reas,
incluindo Qualidade, RH e Scrum, que podem ser teis no processo de Retrospectiva do Projeto. Tambm
podem haver sugestes de Recomendaes do Scrum Guidance Body, sobre a forma como a Reunio de
Retrospectiva do Projeto deve ser conduzida.

268 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


12 RELEASE

12.2.3 Sadas

12.2.3.1 Pontos de Melhoria Aconcordados*

Descrito na seo 11.3.3.1.

12.2.3.2 Itens de Ao Atribuda e Datas de Vencimento*

Descrito na seo 11.3.3.2.

12.2.3.3 Itens No Funcionais Propostos para o Backlog do Produto do Programa e para o


Backlog Priorizado do Produto

Quando o Backlog do Produto do Programa ou Backlog Priorizado do Produto so inicialmente


desenvolvidos, so baseados em Estrias de Usurios e funcionalidades requeridas. Muitas vezes, os
requisitos no-funcionais podem no ser totalmente definidos nas fases iniciais do projeto, e podem surgir
durante a Reviso do Sprint, Retrospectiva do Sprint ou durante as Reunies de Retrospectiva do Projeto.
Esses itens devem ser adicionados ao Backlog do Produto do Programa (para o programa) e Backlog
Priorizado do Produto (para o projeto), assim que sejam descobertos. Alguns exemplos de requisitos no-
funcionais incluem; o tempo de resposta, limitaes de capacidade e as questes relacionadas com a
segurana.

12

12.2.3.4 Recomendaes Atualizadas do Scrum Guidance Body

Descrito nas sees 8.1.1.12 e 11.3.3.5

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 269


12 RELEASE

12.3 Fase do Diagrama de Fluxo de Dados

Figura 12-7: Fase da ReleaseDiagrama de Fluxo de Dados

270 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

13. Scrum para Projetos Grandes


Este captulo enfatiza aspectos adicionais do Scrum que s so aplicveis em Projetos Grandes. O Scrum
para Projetos Grandes, conforme definido em Um Guia para o Conhecimentos em Scrum (Guia SBOK ),
aplicvel ao seguinte:

Projetos grandes em qualquer indstria


Produtos, servios ou quaisquer outros resultados que sero fornecidos aos stakeholders

O termo produto no Guia SBOK pode referir-se a um produto, servio ou qualquer outra entrega. O
Scrum no apenas aplicado de forma eficaz em projetos pequenos em qualquer indstria, mas tambm
em projetos grandes, complexos, com centenas de membros por time.

Alm dos impactos que um projeto grande tem sobre os processos fundamentais de Scrum entre captulos
8 e 12, este captulo introduz trs processos adicionais que se aplicam a projetos grandes.

Para facilitar a melhor aplicao do framework Scrum, este captulo identifica as entradas, ferramentas e
sadas de cada processo como "obrigatrias" ou "opcionais". As entradas, ferramentas e sadas, indicadas
por asteriscos (*), so obrigatrias, enquanto que as sem asteriscos, so opcionais.

Recomenda-se que o Time Scrum e os indivduos que esto sendo introduzidos aos processos e framework
Scrum, concentrem-se principalmente nas entradas, ferramentas e sadas obrigatrias; enquanto que o
Dono do Produto Chefe, Dono do Produto, Scrum Master Chefe, Scrum Masters, e outros profissionais mais
experientes em Scrum, devem se esforam para obter um conhecimento mais profundo da informao
contida neste captulo inteiro. Tambm importante perceber que, apesar de todos os processos serem
definidos exclusivamente no Guia SBOK , eles no so necessariamente realizados sequencialmente ou 12
separadamente. s vezes, pode ser mais conveniente combinar alguns processos, dependendo dos
requisitos especficos de cada projeto.

Este captulo escrito a partir da perspectiva de um time de projeto grande que coordena as atividades de
vrios Times Scrum em um projeto grande para produzir incrementos/entregveis potencialmente
utilizveis. As informaes adicionais relacionadas utilizao do Scrum para qualquer projeto, grande ou
pequeno, esto disponveis do captulo 2 ao 7, que abrangem os princpios do Scrum e os aspectos do
Scrum.

Projetos Grandes x Projetos Tpicos

Os processos fundamentais do Scrum definidos entre os Captulos 8 e 12 so vlidos para todos os


projetos Scrum e os conceitos mencionados nesses captulos so suficientes para gerenciar projetos Scrum
com poucos Times Scrum - normalmente apenas 1 ou 3 Times Scrum. Os impactos a estes processos
fundamentais do Scrum que s so aplicveis a projetos maiores so descritos no final deste captulo.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 271


13 Scrum Para Projetos Grandes

Quando lidamos com projetos grandes geralmente envolvendo quatro ou mais Times Scrum, diferentes dos
processos definidos entre os Captulos 8 e 12, alguns processos adicionais podem ser necessrios para
abordar os esforos adicionais de coordenao e sincronizao. A definio de um projeto grande pode
depender da empresa e da complexidade dos projetos empreendidos. O critrio-chave para um projeto ser
considerado grande ao invs de pequeno o nmero de Scrum Masters e/ou Donos do Produto que ser
necessrio.

A seguir algumas razes pelas quais necessrio a criao de processos adicionais para projetos grandes:

Maior interao e dependncia entre os Times Scrum, medida que a complexidade aumenta em
um projeto grande
Necessidade de colaborao em um Time de Donos do Produto
Necessidade de gerenciar conflitos, resolver problemas e definir prioridades entre todos os Times
Scrum
Exigncia de especializao, j que alguns Times Scrum podem precisar de recursos
especializados para o desenvolvimento de tarefas especficas (essas habilidades especficas no
so necessrias em todos os Times Scrum).
Necessidade de definir certas diretrizes e padres que devem ser adotados por todos os Times
Scrum (por exemplo, padres de segurana dentro de uma empresa ou diretrizes legais e
governamentais para indstrias especficas). Estas podem precisar serem definidas pelo Scrum
Guidance Body.
Necessidade de criar um ambiente para o projeto, que seria ento usado por todos os Times
Scrum
Necessidade de coordenar os resultados de vrios Times Scrum para criar uma release do projeto
para o projeto grande.
Os processos adicionais associados ao Scrum para Projetos Grandes so os seguintes:

13.1 Criar os Componentes do Projeto GrandeEsse processo define como os diversos Donos do
Produto e Times Scrum trabalham juntos. Tambm so identificados os componentes comuns e recursos
comuns e especializados.

13.2 Conduzir e Coordenar os SprintsEsse processo geralmente relevante somente para os projetos
grandes e aborda os aspectos especficos que devem ser considerados durante cada Sprint. Se necessrio,
as reunies do Scrum de Scrums so conduzidas para coordenar os esforos entre os diversos Times
Scrum.

13.3 Preparar a Release de Projetos Grandes Em alguns projetos grandes, pode fazer sentido para a
empresa ter um Sprint especial antes da release, a fim de se preparar para a release do produto (a ser
decidido pelo time do projeto com base nas necessidades do negcio). Este processo aborda a preparao
do Sprint.

A figura 13-1 mostra todas as entradas, ferramentas e sadas para os processos em Scrum Em Escala para
Projetos Grandes.

272 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

13.1 Criar os Componentes dos 13.2 Conduzir e Coordenar 13.3 Preparar o Release para o
Projetos Grandes Sprints Projeto Grande

ENTRADAS ENTRADAS ENTRADAS


1. Declarao de Viso do Projeto* 1. Times Centrais* 1. Times Centrais*
2. Dono do Produto Chefe* 2. Grande Time Central* 2. Grande Time Central*
3. Scrum Master Chefe* 3. Definio de Pronto* 3. Agenda de Planejamento da Release*
4. Identificar Ambiente* 4. Critrio de Aceitao da Histria de 4. Plano de Preparao da Release
5. Recomendaes do Scrum Guidance Usurio*
Body* 5. Dependncias FERRAMENTAS
6. Donos do Produto* 6. Calendrio do Ambiente 1. Plano de Comunicaes *
7. Scrum Masters* 7. Plano de Preparao da Release 2. Sprint de Preparao da Release
8. Organizao Empresarial* 8. Plano de Colaborao dos Times 3. Mtodos de Preparao da Release
9. Caso de Negcio* Scrum
10. Scrum Master do Programa* 9. Plano de Colaborao dos Donos do
11. Dono do Produto do Programa* Produto SADAS
12. Matriz de Recursos Organizacionais* 10. Recursos Compartilhados 1. Produto Lanvel *
13. 2. Notas da Release
FERRAMENTAS FERRAMENTAS 3. Ambiente de Release
1. Reunies do Scrum de Scrums* 4. Melhorias Recomendadas pelo
1. Reunio de Plano do Ambiente*
2. Expertise do Time * Scrum Guidance Body
2. Planos de Comunicao
3. Planejamento de Recursos para o 3. Reunio de Ambiente
Projeto Grande
4. Determinao de Dependncias
SADAS
1. Entregveis do Sprint*
SADAS 2. Calendrio de Planejamento da
1. Plano de Preparao da Release* Release Atualizado*
2. Critrio de Pronto Mnimo 3. Dependncias Solucionadas
3. Critrio de Aceitao da Histria de 4. Ambiente
Usurio
4. Recursos Compartilhados
5.
6.
Especializao do Time
Melhorias Recomendadas pelo Scrum
12
Guidance Body
7. Plano de Colaborao dos Donos do
Produto
8. Plano de Colaborao dos Times
Scrum
9. Dependncias

Figure 13-1: Overview do Scrum em Escala para Projetos Grandes


Nota: asteriscos (*) representam uma entrada, ferramenta ou sada obrigatria para o processo correspondente

Figura 13-2 Mostra as entradas, ferramentas e as sadas obrigatrias para o processo do Scrum para
Projetos Grandes.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 273


13 Scrum Para Projetos Grandes

13.1 Criar Componentes do 13.2 Conduzir e Coordenar 13.3 Preparar Release do Projeto
Projeto Grande Sprints Grande
ENTRADAS ENTRADAS ENTRADAS
1. Declarao de Viso do Projeto* 1. Times Centrais* 1. Times Centrais*
2. Dono do Produto Chefe * 2. Grande Time Central* 2. Grande Time Central *
3. Scrum Master Chefe* 3. Definio de Pronto* 3. Calendrio de Planejamento de
4. Ambiente Identificado* 4. Critrio de Aceitao da Histria de Release*
5. Recomendaes do Scrum Guidance Usurio*
Body* FERRAMENTAS
FERRAMENTAS 1. Plano de Comunicaes*
FERRAMENTAS 1. Reunies de Scrum de Scrums *
1. Reunio de Plano de Ambiente* 2. Expertise do Time* SADAS
1. Produto Lanvel*
SADAS SADAS
1. Plano de Preparao da Release* 1. Releases do Produto*
2. Calendrio de Planejamento de
Release Atualizado *

Figura 13-2: Scrum em Escala para Projetos Grandes

13.1 Criar os Componentes do Projeto Grande

Figura 13-3 Mostra as entradas, ferramentas e as sadas obrigatrias para o processo de Criar os
Componentes do Projeto Grande.

1. Declarao da Viso de Projeto* 1. Reunio do Plano de Ambiente* 1. Plano de Preparao da Release*


2. Dono do Produto Chefe* 2. Plano de Comunicaes 2. Critrio Mnimo de Pronto
3. Scrum Master Chefe* 3. Planejamento de Recursos do 3. Critrio de Aceitao da Histria de
4. Ambiente Identificado* Projeto Grande Usurio
5. Recomendaes do Scrum 4. Determinao de Dependncias 4. Recursos Compartilhados
Guidance Body * 5. Especializao do Time
6. Donos do Produto 6. Melhorias Recomendadas pelo
7. Scrum Masters Scrum Guidance Body
8. Organizao Empresarial 7. Plano de Colaborao de Donos do
9. Caso de Negcio Produto
10. Scrum Master do Programa 8. Plano de Colaborao de Times
11. Dono do Produto do Programa Scrum
12. Matriz de Recursos Organizacionais 9. Dependncias

Figura 13 3: Criar os Componentes do Projeto Grande Entradas, Ferramentas e Sadas

274 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

Figura 13-4 Mostra toda a relao do processo de Criar os Componentes do Projeto Grande com os
processos fundamentais do Scrum na fase Iniciar.

Figura 13-3: Criar os Componentes do Projeto Grande - Diagrama de Fluxo de Dados

13.1.1 Entradas

13.1.1.1 Declarao de Viso do Projeto *


12
Descrito na seo 8.1.3.2

13.1.1.2 Dono do Produto Chefe*

Descrito na seo 3.4.2

13.1.1.3 Scrum Master Chefe*

Descrito na seo 3.5.1

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 275


13 Scrum Para Projetos Grandes

13.1.1.4 Identificar o Ambiente *

Em um projeto grande, importante identificar o nmero e os tipos de ambientes necessrios porque vrios
Times Scrum estaro trabalhando simultaneamente para realizar o trabalho dos seus respectivos Sprints.
Alguns exemplos de ambientes podem incluir: desenvolvimento de software / reas de teste, rea de
trabalho/recursos, ou limites de processos para cada Time Scrum.

13.1.1.5 Recomendaes do Scrum Guidance Body*

Descrito na seo 8.1.1.11.

Em projetos grandes, o Scrum Guidance Body torna-se um importante recurso de referncia para fornecer
orientaes e promover melhores prticas, a fim de melhorar as chances de sucesso

13.1.1.6 Donos do Produto

O papel bsico de um Dono do Produto o mesmo para projetos pequenos e grandes, e descrito na
seo 3.4. Isso inclui a colaborao dos Donos do Produto com os seus respectivos Times Scrum.

A principal diferena em um Projeto Grande que o Dono do Produto no toma as decises de priorizao
do dia-a-dia como em um projeto pequeno, mas simplesmente prov entradas e recomendaes ao Dono
do Produto Chefe. Alm disso, a interao com os stakeholders distribuda entre todos os Donos do
Produto. Cada Dono do Produto trabalha com um time(s) especfico(s) de acordo com os papis definidos.
Essas responsabilidades e papis so definidos no Plano de Colaborao do Dono do Produto.

Donos do Produto colaboram com o Scrum Master Chefe, Dono do Produto Chefe, Scrum Masters e os
outros Donos do Produto para desenvolver a lista de componentes e recursos necessrios em comum para
todos os times do projeto. Eles tambm ajudam a conceber e aprovar o Plano de Preparao de Releases
que pode incluir teste de integrao de ponta-a-ponta.

13.1.1.7 Scrum Masters

O papel de um Scrum o mesmo para pequenos e grandes projetos e est descrito na seo 3.5.

Um projeto grande geralmente ter vrios Scrum Masters cada um facilitando e garantindo um ambiente
de trabalho produtivo para seu(s) respectivo(s) Time(s) Scrumum Scrum Master pode trabalhar em mais
de um Time Scrum. A identificao dos Scrum Masters feita no processo Identificar Scrum Master e
Stakeholder(s) (ver seo 8.2).

276 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

A colaborao entre mltiplos Times Scrum, facilitada pelos Scrum Masters, definida no Plano de
Colaborao dos Times Scrum (ver seo 13.1.3.8)

Scrum Masters colaboram com o Scrum Master Chefe, Dono do Produto Chefe, outros Scrum Masters e
Donos do Produto para desenvolver a lista de componentes e recursos em comum necessrios para todos
os times ao longo do projeto. Eles tambm ajudam a prover entradas para a criao do Plano de
Preparao de Release.

13.1.1.8 Organizao Empresarial

Organizaes que planejam usar Scrum para projetos grandes devem abraar o framework Scrum. Em um
projeto grande, a organizao deve ser capaz de dar suporte ao esforo comprometendo os recursos
necessrios. Se isso no ocorrer, planos devem ser feitos para conseguir mais recursos como pessoas,
ferramentas e espao de trabalho. imperativo que uma empresa que planeja utilizar o Scrum esteja
preparada para as mudanas na sua cultura de trabalho e hbitos no sentido de verdadeiramente alcanar
os benefcios de utilizar o Scrum.

13.1.1.9 Caso de Negcio

Descrito nas sees 4.4.1, 4.4.2 e 8.1.1.1.

Apesar de um caso de negcio de um projeto grande no ser diferente de um caso de negcio para um
projeto pequeno, uma slida justificativa de negcios cada vez mais importante com o aumento no 12
tamanho de um projeto. Os impactos de negcio relacionados seleo do projeto, bons e principalmente
ruins, so significativamente maiores devido maior quantidade de dinheiro e outros recursos envolvidos
no projeto.

13.1.1.10 Scrum Master do Programa

Descrito na seo 3.5.2.

13.1.1.11 Dono do Produto do Programa

Descrito na seo 3.4.3.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 277


13 Scrum Para Projetos Grandes

13.1.1.12 Matriz Organizacional de Recursos

Em um projeto grande, um ambiente Scrum com numerosos Times Scrum concorrem pela alocao de
recursos e priorizao de tarefas, importante gerenciar os recursos organizacionais de uma maneira tima
para alcanar os objetivos gerais do projeto. Donos de Produto precisam gerenciar a gerao de valor
tendo os Planos Organizacionais em ordem. Os Planos Organizacionais devem compreender os
componentes que sero desenvolvidos e as habilidades, custos e outros recursos necessrios para
desenvolv-los, as velocidades atuais dos Times Scrum para estimar a durao do projeto, requisitos de
comunicao e outras interfaces que os Times Scrum precisam manter.

Descrito na seo 8.2.1.10.

13.1.2 Ferramentas

13.1.2.1 Reunio de Plano de Ambiente*

Uma Reunio de Plano de Ambiente utilizada para definir a agenda/calendrio de como os Times Scrum
compartilharo os ambientes. Por exemplo, com times distribudos trabalhando em diferentes fusos
horrios, se possvel conduzir os testes 24 horas por dia para maximizar o uso dos ambientes. Portanto,
mandatrio criar um calendrio para determinar os perodos de teste para cada time. Para projetos de
software, o Plano de Ambiente tambm pode incluir informaes de como e por quem o cdigo promovido
em cada ambiente.

13.1.2.2 Planos de Comunicao

Planos de Comunicao so essenciais em um projeto grande tal como a falta de ou falha na comunicao
entre os vrios Times Scrum pode ser prejudicial aos esforos colaborativos e resultar em um fracasso no
projeto. Planos de Comunicao devem cobrir mensagens-chave, mtodos de comunicao, canais ou
mecanismos para comunicar as mensagens-chave aos stakeholders apropriados (incluindo como o Dono
do Produto Chefe e outros Donos do Produto comunicaro as prioridades aos Times Scrum),
responsabilidades pelas comunicaes, classificao de informao sensvel, calendrio das atividades de
comunicao e processos para garantir a eficcia da comunicao. Os Planos de Comunicao devem
tambm incluir o tempo e o calendrio das reunies de Scrum de Scrums (SoS) e o modo o qual as
Reunies de SoS sero conduzidas.

Cada Time Scrum pode ter um Plano de Comunicao que especificar os registros que devem ser criados
e mantidos ao longo do projeto e a variedade de mtodos para transmitir as informaes importantes do
projeto aos stakeholders. Isso tambm especificar quem responsvel pelas variadas atividades de
comunicao. Ver seo 12.1.2.2.

278 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

13.1.2.3 Planejar Recursos em Projetos Grandes

Planejar Recursos em Projetos Grandes essencial devido complexidade de alocao dos vrios tipos de
recursos para os numerosos Times Scrum trabalhando em paralelo. Haver competio por recursos
escassos e o Dono do Produto Chefe e outros Donos do Produto devem planejar para entregar o maior
valor na menor quantidade de tempo. Planejar recursos em um projeto grande deve levar em considerao
os vrios custos associados com recursos tal como pessoas, treinamento, hardware e software, servios
externos e espao fsico.

O Dono do Produto Chefe e os demais Donos do Produto podem ter que se coordenar com fontes externas
para adquirir recursos e aumentar o time (por exemplo, recursos externos podem ser necessrios para
trabalhar com o time full-time e pode tambm necessitar interagir com o time de gerenciamento de
fornecedores dentro da empresa). Quando contratar recursos externos, o Dono do Produto Chefe e o time
devem cumprir as polticas da empresa para lidar com recursos externos e fornecedores.

Em projetos grandes, o Dono do Produto Chefe pode precisar considerar planejar recursos para enderear
as necessidades de times especializados e a necessidade para configurar ambientes para numerosos
Times Scrum trabalhando em paralelo. O Dono do Produto Chefe e os demais Donos do Produto podem
colaborar com Scrum Masters e Times Scrum para definir as habilidades especializadas necessrias para o
projeto grande, o nmero de recursos necessrios, Times Scrum que necessitam de habilidades
especializadas e a estimativa de alocao.

13.1.2.4 Determinao de Dependncias

Descrito na seo 9.4.2.3. 12

Em Projetos Grandes, identificar propriamente as dependncias ajuda os Times Scrum a determinar quais
de suas decises e atividades podem impactar outros times. Isso tambm pode influenciar a ordem na qual
um Time Scrum isolado executa suas respectivas tarefas para criar os Entregveis do Sprint.

13.1.3 Sada

13.1.3.1 Plano de Preparao de Release*

Em virtude de todo Sprint criar um produto potencialmente lanvel ou outro entregvel em um projeto
pequeno, uma release pode ser feito depois de qualquer Sprint quando isso faz sentido para o negcio. Em
um projeto grande, certas atividades relacionadas preparao da release podem no ser feitas em todo
Sprint. Por exemplo, um time de projeto pode decidir executar um conjunto completo de testes de
performance custosos e demorados ou realizar um conjunto especial de testes de integrao de ponta-a-

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 279


13 Scrum Para Projetos Grandes

ponta no momento anterior release. Essas atividades esto fora do Critrio de Pronto definido para
Sprints regulares.

Em tais casos, um Sprint de Preparao de Release ser necessrio (ver 13.3 Preparar Release de um
Projeto Grande). Essas descries de negcios associadas com as justificativas de negcio so descritas
no Plano de Preparao de Release. O Plano de Preparao de Release detalha os passos a serem
seguidos por cada Time Scrum e pelo projeto como um todo para confirmar que os requisitos mnimos para
a release foram atendidos e o produto ou componente est preparado para release.

13.1.3.2 Critrio Mnimo de Pronto

Descrito na seo 5.4.3.

Critrio de Pronto descrito na seo 8.5.3.2.

Para projetos grandes, certos aspectos sero considerados como Critrio Mnimo de Pronto, tal como
mover para um ambiente especfico ou atender certos critrios internos antes de passar pelos Testes de
Aceitao do Usurio.

Alm dos Critrios Mnimos de Pronto, Donos do Produto e seus Times Scrum podem definir Critrios de
Pronto adicionais aplicveis para tipos especficos de Histrias de Usurio (por exemplo, para todas as
Histrias de Usurio que levam criao ou mudanas para um website). Se critrios adicionais so
definidos alm dos Critrios Mnimos de Pronto, estes deveriam ser considerados pelos Times Scrum que
esto desenvolvendo os produtos. Exemplos de Critrios de Pronto podem incluir checklists que podem ser
usados em nveis de Sprint e Release.

13.1.3.3 Critrios de Aceitao do Usurio

Descrito na seo 9.1.3.2.

13.1.3.4 Recursos Compartilhados

Recursos compartilhados podem incluir pessoas, ambientes e equipamentos que so necessrios por
algum ou todos os Times Scrum que trabalham no projeto. Em um projeto grande, os recursos
compartilhados podem ser limitados e requisitados por mltiplos Times Scrum ao mesmo tempo. Nesse
contexto, o Dono do Produto Chefe, o Scrum Master Chefe, os outros Donos do Produto e outros Scrum
Masters precisam desenvolver um mtodo a respeito de como esses recursos compartilhados sero
alocados e utilizados. As responsabilidades pelos entregveis do Sprint em um projeto grande so
distribudas entre os numerosos Times Scrum, cada um tendo prioridades e disponibilidade distintas. Um
exemplo de um mtodo para alocao de recursos compartilhados pode ser garantir que esses recursos
so alocados primeiramente para features de valor maior/mais importante e para os times trabalhando

280 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

nestas. Quando solicitaes concorrentes tm prioridades muito similares, o Dono do Produto Chefe deve
decidir a alocao baseada nos requisitos de negcio atuais.

13.1.3.5 Especializao do Time

Em um projeto grande, a Especializao do Time pode ser solicitada. H trs dimenses de Especializao
do Time.

A primeira dimenso a necessidade de concluir tarefas especficas. Por exemplo, um Time Especializado
pode ser um time de integrao que tem um conhecimento especfico de integrao contnua. Esse
conhecimento pode ser especialmente importante para conduo do Sprint de Preparao do Release.

A segunda dimenso a necessidade por habilidades especiais de membros individuais. Teoricamente,


todos os membros do Time Scrum so generalistas e especialistas, pois tm conhecimento em vrias reas
e so experts em pelo menos uma. Contudo, isso pode no ser o caso em um projeto grande. Membros de
Time Especializados podem possuir habilidades especficas tal como um domnio de conhecimento
especial como segurana que pode no estar disponvel em todos os times de projeto para os quais isso
necessrio. Para um projeto grande, pode ser extremamente custoso treinar todos em todos os domnios.
Esses experts com habilidades e conhecimento especializados podem trabalhar como membros
temporrios em diferentes times, e s vezes pode ser necessrio contrat-los de fontes externas.
importante lembrar que adicionar um novo membro no time impactar a velocidade do time.

A Terceira dimenso aquela em podem haver limitaes na flexibilidade do time. Como mencionado
acima, em um projeto grande seria extremamente custoso treinar todos em todos os domnios. Isso significa
que todos os times tero um ou mais domnios nos quais eles tem uma expertise significativa, alguns 12
domnios que eles podem e trabalharo com algumas entradas e treinamento e outros domnios nos quais
eles no so aptos a trabalhar. Quando ocorre o Planejamento do Sprint, todos os times tero um
subconjunto de Histrias de Usurio que so logicamente suas baseadas em suas especialidades, algumas
que eles podem trabalhar e outras que eles no podem trabalhar pois no possuem o
conhecimento/habilidades.

Isso resultado em algum nvel de risco para o projeto. Todas as Histrias de Usurio com prioridade alta
podem no ser possveis de serem concludas em um nico Sprint. Os Times podem precisar trabalhar em
Histrias de Usurio de menor prioridade enquanto esperam a disponibilidade dos membros do time
especialistas.

13.1.3.6 Melhorias Recomendadas pelo Scrum Guidance Body

Como resultado do planejamento de um projeto grande, sugestes podem ser feitas para rever ou melhorar
as Recomendaes do Scrum Guidance Body. Se o Guidance Body aceita essas sugestes, as mesmas
sero incorporadas como atualizao da documentao do Scrum Guidance Body.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 281


13 Scrum Para Projetos Grandes

13.1.3.7 Plano de Colaborao de Donos do Produto

O Plano de Colaborao de Donos do Produto deve definir como vrios Donos do Produto colaboram com
o Dono do Produto Chefe. Minimamente, deve definir com quantos Times Scrum um Dono do Produto
consegue lidar (baseado em experincia, tempo e domnio de conhecimento), como o trabalho de levantar
requisitos juntos aos stakeholders ser distribudo entre os Donos do Produto, como o Backlog Priorizado
do Produto ser atualizado com novos ou em mudanas nos requerimentos, e como os Donos do Produto
colaboraro com mltiplos Times Scrum. Deve-se ressaltar que cada Time Scrum colaborar com um nico
Dono do Produto; contudo, um Dono do Produto pode trabalhar com mais de um Time Scrum, se
necessrio.

13.1.3.8 Plano de Colaborao de Times Scrum

O Plano de Colaborao de Time Scrum define como os vrios Times Scrum colaboram entre si para gerar
o maior valor no menor tempo possvel. Esse plano deve incluir informaes de domnios especializados
atribudos a times qualificados, como os times suportaro o refinamento do Backlog Priorizado do Produto e
as estimativas (por exemplo, decidido quais membros dos times participaro das sesses de refinamento e
dos exerccios de estimativa em alto nvel) e como os times organizar-se-o nas reunies de Scrum de
Scrums (SoS).

Esse plano tambm poder conter informaes de como cada Time Scrum ser preparado (por exemplo,
haver um coach alm de seu respectivo Scrum Master; no caso de times distribudos haver um Scrum
Master em cada localidade; como os membros do time colaboraro com Scrum Masters colocados e com
Scrum Masters que no esto colocados?).

13.1.3.9 Dependncias

Descrito na seo 9.4.3.3.

13.1.3.10 Calendrio de Ambiente

O Calendrio de Ambiente criado durante a Reunio de Plano de Ambiente e utilizado para a


coordenao das atividades do Sprint no processo Conduzir e Coordenar o Sprint (13.2). Descreve as
janelas de teste para cada time.

282 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

13.2 Conduzir e Coordenar Sprints

A figura 13-5 mostra todas as entradas, ferramentas e sadas para o processo Conduzir e Coordenar
Sprints.

1. Times Centrais* 1. Reunies de Scrum of Scrums* 1. Entregveis do Sprint*


2. Grande Time Central* 2. Expertise do Time* 2. Calendrio de Planejamento de
3. Definio de Pronto* 3. Reunio de Ambiente Release Atualizado*
4. Critrios de Aceitao de Histrias 3. Dependncias Solucionadas
de Usurio * 4. Ambiente (s)
5. Dependnicas
6. Calendrio de Ambiente
7. Plano de Preparao de Release
8. Plano de Colaborao de Times
Scrum
9. Plano de Colaborao de Donos do
Produto
10. Recursos Compartilhados

Figura 13-4: Conduzir e Coordenar Sprints Entradas, Ferramentas e Sadas

A figura 13-6 mostra todos os relacionados do processo Conduzir e Coordenar Sprints aos processos 12
fundamentais do Scrum.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 283


13 Scrum Para Projetos Grandes

Figura 13-5: Conduzir e Coordenar Sprints Diagrama de Fluxo de Dados

13.2.1 Entradas

13.2.1.1 Times Centrais*

Times Centrais consistindo de Scrum Master, Dono do Produto e Time Scrum esto descritos nas sees
8.4.1.1 e 3.3.1.

13.2.1.2 Grande Time Central*

O Grande Time Central constitudo do Dono do Produto Chefe, Scrum Master Chefe, Scrum Masters,
Donos do Produto e membros selecionados dos Times Scrum trabalhando no projeto grande. Ter um
grande time core que inclui todos os membros de todos os times seria impraticvel. Sendo assim, os times
devem selecionar um membro que os representar no Grande Time Central.

284 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

O Scrum Master Chefe clarifica os impedimentos e garante um ambiente de projeto produtivo para todos os
Times Scrum envolvidos no projeto. O Dono do Produto Chefe prepara e mantm o Backlog Priorizado do
Produto geral para o projeto grande, usando-o para coordenar o trabalho entre os Donos do Produto dos
Times Scrum. Os Donos do Produto so responsveis por decidir a prioridade das features e componentes
a serem desenvolvidos pelos Times Scrum que so parte do projeto grande.

Scrum Master Chefe, Dono do Produto Chefe, Scrum Masters, Donos do Produto e os membros
selecionados dos Times Scrum colaboram para desenvolver a lista de componentes e recursos em comum
necessrios para todos os times ao longo do projeto.

13.2.1.3 Definio de Pronto*

Descrito nas sees 8.5.3.2 e 5.4.3.

Se h um Sprint de Preparao da Release, seu Critrio de Pronto normalmente nico e difere do Critrio
de Pronto dos outros Sprints. Os Critrios de Pronto so definidos com o propsito de garantir que os
Entregveis do Sprint so potencialmente lanveis. O Sprint de Preparao da Release enderea todos
os problemas que no foram endereados nos Sprints regulares baseados nas decises de negcio
deliberadas e so inseridas no Plano de Preparao da Release.

13.2.1.4 Critrios de Aceitao de Histria de Usurio *

Descrito na seo 9.1.3.2.

12
13.2.1.5 Dependncias

Descrito nas sees 9.3.2.4 e 9.3.3.3.

13.2.1.6 Calendrio de Ambiente

Calendrio de Ambiente uma agenda/calendrio de como os Times Scrum compartilharo os ambientes.


Contm os dias alocados e as janelas de tempo para cada time para usar o ambiente.

13.2.1.7 Plano de Preparao de Release

Descrito na seo 13.1.3.1.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 285


13 Scrum Para Projetos Grandes

13.2.1.8 Plano de Colaborao de Times Scrum

Descrito na seo 13.1.3.9.

13.2.1.9 Plano de Colaborao de Donos do Produto

Descrito na seo 13.1.3.7.

13.2.1.10 Recursos Compartilhados

Recursos Compartilhados podem incluir pessoas, ambiente e equipamentos necessrio por todos ou alguns
dos Times Scrum trabalhando no projeto. Em um projeto grande, os recursos compartilhados podem ser
limitados e so necessrios por todos ou alguns dos Times Scrum ao mesmo tempo. Ver seo 13.1.3.4.

13.2.2 Ferramentas

13.2.2.1 Reunio de Scrum de Scrums*

Uma Reunio de Scrum de Scrums um elemento importante quando se escala Scrum em projetos
grandes. Tipicamente, h um representante de cada Time Scrum na reunio normalmente o Scrum
Master mas tambm comum para outros membros de um Time Scrum atender reunio se necessrio.
Essa reunio geralmente facilitada pelo Scrum Master Chefe e a inteno focar nas reas de
coordenao e integrao entre os diferentes Times Scrum.

Essas reunies so preferencialmente curtas onde um representante de cada Time Scrum procura
compartilhar o status do seu respectivo time. Normalmente no so time-boxed para permitir um maior
compartilhamento de informaes entre os Times Scrum. A Reunio Scrum de Scrums (SoS) realizada
em intervalos predeterminados ou quando solicitado pelos Times Scrum de modo a facilitar o
compartilhamento da informao entre os vrios Times Scrum. Problemas, dependncias e riscos que
impactam mltiplos Times Scrum podem ser monitorados de perto, o que ajuda os mltiplos times
trabalhando em um projeto grande a melhor coordenar e integrar o trabalho. responsabilidade do Scrum
Master Chefe (ou outro Scrum Master que facilita as Reunies de SoS) garantir que todos os
representantes tm um ambiente propcio a um compartilhamento de informaes aberto e honesto,
incluindo feedback para representantes de outros times. Em projetos grandes, envolvendo um nmero
significativo de times, mltiplos nveis dessas reunies podem ser convocados para compartilhar o status
dos respectivos times.

286 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

Cada representante do Time Scrum prover atualizaes do seu time por vez. Essas atualizaes so
fornecidas em forma de respostas a quatro perguntas especficas:

a. No que meu time trabalhou desde a ltima reunio?


b. O que meu time far at a prxima reunio?
c. O que os outros times estavam esperando que nosso time finalizasse que permanece
pendente?
d. O que nosso time est planejando fazer que pode afetar outros times?
As respostas a essas quatro perguntas fornecem informaes que permitem a cada time claramente
entender o status do trabalho de todos os outros times.

13.2.2.2 Expertise do Time *

Descrito na seo 10.1.2.1.

Alm disso, para projetos grandes isso tambm inclui o conhecimento do Dono do Produto Chefe e do
Scrum Master Chefe da Expertise do Time. O ltimo til para avaliar opes para desenvolver as Histrias
de Usurio em cada Sprint.

13.2.2.3 Reunio de Ambiente

Essa reunio conduzida para identificar os tipos e quantidade de ambientes necessrios para
desenvolver, gerenciar e testar os entregveis do projeto. Nessa reunio, os recursos necessrios para 12
estabelecer os ambientes solicitados tambm so discutidos.

13.2.3 Sadas

13.2.3.1 Entregveis do Sprint *

Os entregveis do Sprint so os produtos potencialmente lanveis desenvolvidos pelos Times Scrum ao


final de cada Sprint. Os entregveis devem incluir todas as features e funcionalidades definidas nas
Histrias de Usurio includas no Sprint e devem ter sido testadas com sucesso.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 287


13 Scrum Para Projetos Grandes

13.2.3.2 Calendrio de Planejamento de Release Atualizado*

O Plano de Preparao de Release detalha os passos que cada Time Scrum e o projeto como um todo
devem seguir para confirmar que os requisitos mnimos para release foram atendidos. Isso pode ser
atualizado com mudanas identificadas nesse processo.

13.2.3.3 Dependncias Solucionadas

Dependncias entre Histrias de Usurio, tarefas e os recursos necessrios para converter Histrias de
Usurio em entregveis requerem que o projeto tenha um plano de ao de dependncias. Esse plano
compreende todas as aes necessrias para gerenciar todos os tipos de dependncias mandatrias,
discricionrias, externas e internas.

13.2.3.4 Ambiente(s)

Refere-se identificao e documentaes de todos os ambientes necessrios para desenvolver e testar


os entregveis do projeto.

288 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

13.3 Preparar Release do Projeto Grande

A figura 13-7 mostra todas as entradas, ferramentas e sadas para o processo Preparar Release do Projeto
Grande.

1. Times Centrais* 1. Planos de Comunicao* 1. Produto Lanvel *


2. Grande Time Central* 2. Sprint de Preparao de Release 2. Notas de Release
3. Calendrio de Planejamento de 3. Mtodos de Preparao de Release 3. Ambiente de Release Environment
Release* 4. Melhorias Recomendadas pelo
4. Plano de Preparao de Release Scrum Guidance Body

Figura 13-6: Preparar Release do Projeto Grande Entradas, Ferramentas e Sadas

A figura 13-8 exibe os relacionamentos do processo Preparar Release do Projeto Grande aos processos
fundamentais do Scrum.

12

Figura 13-7: Preparar Release do Projeto Grande Diagrama de Fluxo de Dados

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 289


13 Scrum Para Projetos Grandes

13.3.1 Entradas

13.3.1.1 Times Centrais*

Descrito nas sees 8.4.1.1 e 3.3.1.

13.3.1.2 Grande Time Central*

Descrito na seo 13.2.1.2.

13.3.1.3 Calendrio de Planejamento de Release*

Descrito na seo 8.6.3.1.

13.3.1.4 Plano de Preparao de Release

Descrito na seo 13.1.3.1.

13.3.2 Ferramentas

13.3.2.1 Plano de Comunicaes*

Descrito nas sees 12.1.2.2 e 13.1.2.1.

13.3.2.2 Sprint de Preparao de Release

Se h uma necessidade de tarefas especficas serem executadas para preparar-se para a Release e
confirmar que os requisitos mnimos para a release foram atendidos, essas tarefas so executadas no
Sprint de Preparao de Release. Um Sprint de Preparao de Release, se necessrio, s feito uma vez
por Release sendo o Sprint anterior Release. Em um Sprint de Preparao de Release, nenhuma Histria
de Usurio do Backlog Priorizado do Produto desenvolvida. Ao invs disso, as tarefas identificadas no
Plano de Preparao de Release (ver 13.1.3.1) so executadas.

290 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

importante lembrar: essas tarefas so executadas em um Sprint de Preparao de Release como


resultado de uma deciso de negcio. Isso no altera a obrigao de atende os Critrios de Aceitao e de
Pronto ao final de cada Sprint individual.

Um Sprint de Preparao de Release no obrigatrio. Apesar de no ser obrigatrio, em muitos projetos


grandes uma deciso de negcios realizada para conduzir o Sprint de Preparao de Release.

13.3.2.3 Mtodos de Preparao do Release

Mtodos de Preparao do Release so os mtodos utilizados para executar as tarefas identificadas no


Plano de Preparao do Release no sentido de preparar os entregveis para serem lanados/liberados.
Esses mtodos podem ser especficos do projeto, porm o mais comum serem vlidos a um nvel de
portflio ou pelo menos a nvel de programa. Eles podem ser definidos no Scrum Guidance Body.

13.3.3 Sadas

13.3.3.1 Produto Lanvel *

Um Produto Lanvel um entregvel ou um incremento de produto que atende os Critrios de Aceitao


definidos pelo cliente e pelo Dono do Produto. Ele pode estar pronto para ser lanado ou liberado ao final
de um Sprint de Preparao de Release.
12

13.3.3.2 Notas de Release

Notas de Release so os documentos fornecidos ao cliente junto com a release do produto. Esses incluem
critrios de lanamento externos ou de mercado para o produto a ser entregue.

13.3.3.3 Ambiente de Release

O Ambiente de Release necessrio para suporte a release em/para produo.

13.3.3.4 Melhorias Recomendadas pelo Scrum Guidance Body

Descrito na seo 13.1.3.6.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 291


13 Scrum Para Projetos Grandes

13.4 Impacto de Projetos Grandes aos Processos Fundamentais do


Scrum

Apesar dos processos fundamentais do Scrum descritos nos captulos 8 at 12 permanecerem vlidos para
projetos grandes, h impactos especficos que devem ser notados. A tabela 13-1 esboa os impactos de
um projeto grande aos processos fundamentais do Scrum.

Processo Descrio do(s) Impacto do Processo para um Projeto Grande

8.1 Criar a Viso do Projeto Sada Adicional: Dono do Produto Chefe Identificado*
Para um projeto grande um Dono do Produto Chefe identificado como uma sada
desse processo. Assim como, mltiplos Donos do Produto devem ser identificados,
enquanto que projetos pequenos requerem somente um Dono do Produto.

Sada Adicional: Scrum Master Chefe Identificado *


Similar ao Dono do Produto Chefe, o Scrum Master Chefe tambm deve ser
identificado para um projeto grande.

8.2 Identificar Scrum Master Sada: Stakeholders Identificados


e Stakeholder(s) Alm de identificar os stakeholders nesse processo, para um projeto grande alguns
dos membros-chave dos vrios Times Scrum tambm precisam ser identificados
como skateholders importantes. Esses stakeholders sero entradas ao processo
Criar Componentes do Projeto Grande.

292 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

Processo Descrio do(s) Impacto do Processo para um Projeto Grande

8.3 Formar o Time Scrum Entrada Adicional: Dono do Produto Chefe


Descrito na seo 3.4.2. Para um projeto grande, o Dono do Produto Chefe estaria
envolvido na determinao da formao dos Times Scrum e ter entradas a respeito
dos membros para os times. O Dono do Produto Chefe atenderia aos interesses do
projeto grande como um todo, enquanto que Donos do Produto estariam focados no
nvel do time individual.

Entrada Adicional: Scrum Master Chefe


Descrito na seo 3.5.1. Para um projeto grande, o Scrum Master Chefe estaria
envolvido na determinao da formao dos Times Scrum e ter entradas a respeito
dos membros para os times. O Scrum Master Chefe atenderia aos interesses do
projeto grande como um todo, enquanto que Scrum Masters estariam focados no
nvel do time individual.
Entrada Adicional: Recursos Compartilhados
Descrito na seo 13.1.3.4. O conhecimento de quaisquer recursos compartilhados
pelos Times Scrum seria uma entrada necessria na formao dos Times Scrum
individuais.

Entrada Adicional: Especializao do Time


Descrito na seo 13.1.3.5.

8.4 Desenvolver pico(s) Entrada Adicional: Plano de Colaborao de Donos do Produto


Descrito na seo 13.1.3.7. Essa uma das principais sadas do processo Criar os 12
Componentes do Projeto Grande. Isso define como os mltiplos Donos do Produto
trabalham em conjunto com o Dono do Produto Chefe. Enderea como eles
trabalham com os stakeholders para coletar requisitos, atualizam o Backlog
Priorizado do Produto e trabalham com os Mltiplos Times Scrum. Haver apenas
um Dono do Produto interagindo diretamente com cada Time Scrum. Contudo,
decises precisam ser tomadas a respeito de como os Times Scrum sero alocados
entre os Donos do Produto e com quantos Times Scrum cada Dono do Produto ir
trabalhar.

8.5 Criar o Backlog Entrada Adicional: Plano de Colaborao de Donos do Produto


Priorizado do Produto Descrito na seo 13.1.3.7. Uma vez que o Plano de Colaborao define como os
Donos do Produto atualizam o Backlog Priorizado do Produto essa uma importante
entrada a esse processo.
Entrada Adicional: Dependncias
Descrito na seo 9.4.2.3.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 293


13 Scrum Para Projetos Grandes

Processo Descrio do(s) Impacto do Processo para um Projeto Grande

8.6 Conduzir o Planejamento Entrada Adicional: Scrum Master Chefe


do Release Planning Descrito na seo 3.5.1.

Entrada Adicional: Plano de Preparao de Release


Descrito na seo 13.1.3.1. O Plano de Preparao do Release inclui informaes
importantes que impactam o planejamento do Release como um todo.

9.1 Criar Histrias de Usurio Entrada Adicional: Plano de Colaborao de Donos do Produto
Descrito na seo 13.1.3.7.

Entrada Adicional: Plano de Colaborao de Times Scrum


Descrito na seo 13.1.3.8.

9.2 Estimar Histrias de Entrada Adicional: Plano de Colaborao do Donos do Produto


Usurio Descrito na seo 13.1.3.7.

Entrada Adicional: Plano de Colaborao de Times Scrum


Descrito na seo 13.1.3.8.

9.3 Comprometer Histrias Sem mudana


de Usurio

9.4 Identificar Tarefas Sem mudana

9.5 Estimar Tarefas Sem mudana

9.6 Criar o Backlog do Sprint Sem mudana

10.1 Criar Entregveis Sem mudana

10.2 Conduzir a Reunio Sem mudana


Diria

294 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


13 Scrum Para Projetos Grandes

Processo Descrio do(s) Impacto do Processo para um Projeto Grande

10.3 Refinar o Backlog Entrada Adicional: Plano de Colaborao de Donos do Produto


Priorizado do Produto Descrito na seo 13.1.3.7. O Plano de Colaborao do Dono do Produto define
como os Donos do Produto atualizam o Backlog Priorizado do Produto.

Entrada Adicional: Plano de Colaborao de Times Scrum


Descrito na seo 13.1.3.8. O Plano de Colaborao de Times Scrum define como
os times participam do refinamento do Backlog Priorizado do Produto. Esse plano
tambm definiria quais representantes dos times seriam envolvidos no processo de
refinamento e como esses so selecionados.

Entrada Adicional: Especializao do Time


Descrito na seo 13.1.3.5.

Sada Adicional: Plano de Preparao de Release Atualizado


Mudanas no Backlog do Produto feitas durante o refinamento do Backlog do
Produto podem impactar o Plano de Preparao do Release (ver seo 13.1.3.1).
11.1 Demonstrar e Validar o Esse processo executado individualmente por cada Time Scrum. Para cada time,
Sprint o respectivo Dono do Produto aprova as Histrias de Usurio, contudo isso pode ser
um tanto complexo devido s interdependncias. Pode haver casos que o Dono do
Produto Chefe participa de todas as Reunies de Reviso do Sprint de todos os
times. Frequentemente, uma validao de ponta-a-ponta pode ser necessria uma
vez que alguns itens podem surgir para serem desenvolvidos na validao individual
por time pois podem no atender aos critrios de aceitao finais quando 12
revisados como parte da validao de ponta-a-ponta.
11.2 Retrospectiva do Sprint Entrada Adicional: Plano de Colaborao do Donos do Produto
Descrito na seo 13.1.3.7.Em Projetos Grandes, o refinamento do Backlog do
Produto pode ser particularmente difcil. Se no feito efetivamente, o refinamento
pode causar problemas e desperdcio de esforo entre os times. Portanto,
recomendado que o refinamento seja discutido como parte da retrospectiva,
especialmente focando em como os vrios Donos do Produto interagem entre si e
com os Time Scrum para conduzir efetivamente o refinamento do backlog.

Entrada Adicional: Plano de Colaborao de Times Scrum


Descrito na seo 13.1.3.8. Em Projetos Grandes, o refinamento do Backlog do
Produto pode ser particularmente difcil. Se no feito efetivamente, o refinamento
pode causar problemas e desperdcio de esforo entre os times. Portanto,
recomendado que o refinamento seja discutido como parte da retrospectiva,
especialmente focando na interao entre os vrios Times Scrum e como estes
interagem com Donos do Produto para atividades de refinamento.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 295


13 Scrum Para Projetos Grandes

Processo Descrio do(s) Impacto do Processo para um Projeto Grande

12.1 Lanar Entregveis Entrada Adicional: Dono do Produto Chefe


Descrito na seo 3.4.2.

Entrada Adicional: Scrum Master Chefe


Descrito na seo 3.5.1.

Entrada Adicional: Notas de Release


Descrito na seo 13.3.3.2.

Para Projetos Grandes, a sada das Notas de Release do processo Preparar o


Release de Projeto Grande tornar-se-iam uma entrada para esse processo.
12.2 Retrospectiva do Entrada Adicional: Dono do Produto Chefe
Projeto Descrito na seo 3.4.2.

Entrada Adicional: Scrum Master Chefe


Descrito na seo 3.5.1.
Tabela 13-1: Resumo dos Impactos de Projetos Grandes aos Processos Fundamentais do Scrum

296 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14. SCALING SCRUM FOR THE ENTERPRISE

This chapter includes the processes related to scaling Scrum for the Enterprise: Create Program or Portfolio
Components, Review and Update Scrum Guidance Body, Create and Groom Program or Portfolio Backlog,
Coordinate Program or Portfolio Components, and Retrospect Program or Portfolio Releases.

Scaling Scrum for the Enterprise, as defined in A Guide to the Scrum Body of Knowledge (SBOK Guide),
is applicable to the following:

Portfolios, programs, and/or projects in any industry


Products, services, or any other results to be delivered to stakeholders
Projects of any size or complexity
The term product in the SBOK Guide may refer to a product, service, or other deliverable. Scrum can be
applied effectively to any project in any industryfrom small projects or teams with as few as six team
members to large, complex projects with up to several hundred team members.

To facilitate the best application of the Scrum framework, this chapter identifies inputs, tools, and outputs for
each process as either mandatory or optional. Inputs, tools, and outputs denoted by asterisks (*) are
mandatory, or considered critical to success, whereas those with no asterisks are optional.

It is recommended that those individuals being introduced to the Scrum framework and processes focus
primarily on the mandatory inputs, tools, and outputs; while other more experienced Scrum practitioners
strive to attain a more thorough knowledge of the information in this entire chapter.

12

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 297


14 Escalar Scrum para a Empresa

Figure 14-1 provides an overview of the Scaling Scrum for Enterprise processes, which are as follows:

14.1 Create Program or Portfolio ComponentsIn this process, the Program or Portfolio Product Owner
and key stakeholders identify common components and resources required for the program or portfolio. The
Minimum Done Criteria are defined and all stakeholders are identified.

14.2 Review and Update Scrum Guidance BodyIn this process, the Scrum Guidance Body
Recommendations are regularly reviewed by the members of the Scrum Guidance Body and are updated
when and if necessary. In this process, changes in the membership of the Scrum Guidance Body are also
handled.

14.3 Create and Groom Program or Portfolio BacklogIn this process, the Program or Portfolio Backlog
is created, updated, and maintained. Suggested improvements for the Scrum Guidance Body
Recommendations may be made and implementation deadlines may be adjusted based on changed
requirements and/or progress of the projects in the program or portfolio.

14.4 Coordinate Program or Portfolio ComponentsIn this process, components of the program or
portfolio are coordinated. Dependencies between projects are addressed, common impediments are
discussed, and best practices are shared. Sometimes, recommendations for improvements of the Scrum
Guidance Body are made.

14.5 Retrospect Program or Portfolio ReleasesIn this process, the Program or Portfolio Product Owner
and key stakeholders get together to retrospect a program or portfolio Release and internalize the lessons
learned. Often, these lessons learned lead to agreed actionable improvements to be implemented in future
releases. Sometimes, improvements to the Scrum Guidance Body may be recommended.

298 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.1 Create Program or 14.2 Review and Update 14.3 Create and Groom Program or Portfolio Backlog
Portfolio Components Scrum Guidance Body
INPUTS INPUTS INPUTS
1. Company Vision and Mission 1. Regulations* 1. Company Vision and Mission*
* 2. Recommended Scrum 2. Prioritized Portfolio Backlog*
2. Portfolio Product Owner* Guidance Body 3. Prioritized Program Backlog*
3. Portfolio Scrum Master* Improvements* 4. Portfolio Product Owner*
4. Program Product Owner* 3. Scrum Guidance Body 5. Portfolio Scrum Master*
5. Program Scrum Master* Members 6. Program Product Owner*
6. Organizational Resource 7. Program Scrum Master*
TOOLS
Matrix 8. Scrum Guidance Body Recommendations
1. Members Selection Criteria*
7. Scrum Guidance Body 9. Company Policies
2. Benchmarking
Recommendations 10. Industry Standards
3. Scrum Guidance Body
8. Key Stakeholders 11. Assessment/Benchmarking Results
Meetings
TOOLS TOOLS
OUTPUTS
1. Communication Plan(s)* 1. Prioritized Program or Portfolio Backlog Review Meetings*
1. Updated Scrum Guidance
2. Company Human Resource 2. Communication Techniques*
Body Recommendations*
Plans* 3. User Story Prioritization Methods
2. Actionable Escalations
3. Stakeholder Analysis 4. User Story Workshop
3. Updated Scrum Guidance
OUTPUTS 5. User or Customer Interviews
Body Membership
1. Minimum Done Criteria* 6. Questionnaires
4. Rejected Updates to Scrum
2. User Story Acceptance OUTPUTS
Guidance Body
Criteria*
Recommendations 1. Updated Prioritized Program or Portfolio Backlog*
3. Shared Resources*
2. Recommended Scrum Guidance Body Improvements*
4. Identified Stakeholders*
3. Updated Implementation Deadlines for Projects*
5. Recommended Scrum
4. Personas
Guidance Body
5. Identified Risks
Improvements

14.4 Coordinate Program or Portfolio 14.5 Retrospect Program or Portfolio Releases


Components
INPUTS INPUTS
1. Definition of Done* 1. Portfolio Product Owner*
2. Known Dependencies* 2. Portfolio Scrum Master*
3. Prioritized Program or Portfolio Backlog* 3. Program Product Owner*
4. Portfolio Product Owner* 4. Program Scrum Master* 12
5. Portfolio Scrum Master* 5. Stakeholders
6. Program Product Owner* 6. Scrum Guidance Body Recommendations
7. Program Scrum Master* TOOLS
8. Potentially Shippable Deliverables from Projects 1. Retrospect Program or Portfolio Meeting*
9. Impediments Logs 2. Scrum Guidance Body Expertise
10. Prioritized Product Backlogs
11. Scrum Team Lessons Learned OUTPUTS
12. Release Planning Schedules 1. Agreed Actionable Improvements*
2. Assigned Action Items and Due Dates*
TOOLS 3. Recommended Scrum Guidance Body Improvements
1. Scrum of Scrums (SoS) Meeting*
2. Scrum of Scrum of Scrums (SoSoS) Meeting
3. Communication Techniques
OUTPUTS
1. Updated Impediments Logs*
2. Updated Dependencies*
3. Recommended Scrum Guidance Body Improvements

Figure 14-8: Scaling Scrum for the Enterprise Overview


Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 299


14 Escalar Scrum para a Empresa

Figure 14-2 below shows the mandatory inputs, tools, and outputs for processes in Scaling Scrum for the
Enterprise.

14.1 Create Program or 14.2 Review and Update 14.3 Create and Groom
Portfolio Components Scrum Guidance Body Program or Portfolio Backlog

INPUTS INPUTS INPUTS


1. Company Vision and Mission* 1. Regulations* 1. Company Vision and Mission*
2. Portfolio Product Owner* 2. Recommended Scrum Guidance 2. Prioritized Portfolio Backlog*
3. Portfolio Scrum Master* Body Improvements* 3. Prioritized Program Backlog*
4. Program Product Owner* 4. Portfolio Scrum Master*
5. Program Scrum Master* TOOLS 5. Portfolio Product Owner*
TOOLS 1. Member Selection Criteria* 6. Program Product Owner*
1. Communication plan(s)* OUTPUTS 7. Program Scrum Master*
2. Company Human Resource 1. Updated Scrum Guidance Body TOOLS
Plans* Recommendations* 1. Prioritized Program or Portfolio
OUTPUTS Backlog Review Meetings*
1. Minimum Done Criteria* 2. Communication Techniques*
2. User Story Acceptance Criteria* OUTPUTS
3. Shared Resources* 1. Updated Program or Portfolio
4. Identified Stakeholders* Backlog*
2. Updated Scrum Guidance Body
Recommendations*
3. Updated Implementation
Deadlines for Projects*

14.4 Coordinate Program or 14.5 Retrospect Program or


Portfolio Components Portfolio Releases

INPUTS INPUTS
1. Definition of Done* 1. Portfolio Product Owner*
2. Known Dependencies* 2. Program Product Owner*
3. Prioritized Program or Portfolio Backlog* 3. Portfolio Scrum Master*
4. Portfolio Product Owner* 4. Program Scrum Master*
5. Portfolio Scrum Master*
TOOLS
6. Program Product Owner*
1. Retrospect Program or Portfolio
7. Program Scrum Master*
Meeting*
TOOLS
OUTPUTS
1. Scrum of Scrums (SoS) Meeting*
1. Agreed Actionable Improvements*
OUTPUTS 2. Assigned Action Items and Due Dates*
1. Updated Impediments Logs*
2. Updated Dependencies*

Figure 14-9: Scaling Scrum for the Enterprise


Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

300 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.1 Create Program or Portfolio Components


Figure 14-3 shows all the inputs, tools, and outputs for the Create Program or Portfolio Components
process.

1. Company Vision and Mission* 1. Communication Plan(s)* 1. Minimum Done Criteria*


2. Portfolio Product Owner* 2. Company Human Resource Plans* 2. User Story Acceptance Criteria*
3. Portfolio Scrum Master* 3. Stakeholder Analysis 3. Shared Resources*
4. Program Product Owner* 4. Identified Stakeholders*
5. Program Scrum Master* 5. Recommended Scrum Guidance Body
6. Organizational Resource Matrix Improvements
7. Scrum Guidance Body
Recommendations
8. Key Stakeholders

Figure 14-10: Create Program or Portfolio ComponentsInputs, Tools, and Outputs

Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

12

Figure 14-11: Create Program or Portfolio Components Data Flow Diagram

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 301


14 Escalar Scrum para a Empresa

14.1.1 Inputs

14.1.1.1 Company Vision and Mission*

Company Vision and Company Mission statements are described in sections 8.1.1.8 and 8.1.1.9,
respectively.

Both, the company vision and the company mission are important for any project, but even more so for
programs and especially at the portfolio level. Programs and portfolios should be driven by the overall
mission and vision of the enterprise as this ensures unity of effort throughout the organization.

14.1.1.2 Portfolio Product Owner*

Described in sections 3.4.4.

14.1.1.3 Portfolio Scrum Master*

Described in sections 3.5.3.

14.1.1.4 Program Product Owner*

Described in section 3.4.3.

In a project, the Program Product Owner is one of multiple stakeholders. At the program level, the Program
Product Owner plays a similar role as the Product Owner does in a project. He or she is responsible for and
drives the creation and grooming of program components.

14.1.1.5 Program Scrum Master*

Described in section 3.5.2.

In a project, the Program Scrum Master is one of multiple stakeholders. At the program level, the Program
Scrum Master plays a similar role as the Scrum Master does in a project. He or she is a facilitator, solves
problems and removes impediments at the Program Level.

302 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.1.1.6 Organizational Resource Matrix

Described in section 8.2.1.8.

14.1.1.7 Scrum Guidance Body Recommendations

Described in section 8.1.1.11.

Scrum Guidance Body Recommendations are especially important at program and portfolio levels as
appropriate guidance is needed for a potentially significant number of projects.

14.1.1.8 Key Stakeholders

While many stakeholders will be identified in this process, several key stakeholders will already be known.
For example, key stakeholders at the portfolio level include members of the executive board of a company
and governmental organizations. Key stakeholders at the program level include the sponsor(s) of the
program or associated projects and senior executives.

Refer to related sections 1.4.3.1, 3.3.2, and 6.4.2.1.

14.1.2 Tools
12

14.1.2.1 Communication Plan(s)*

Described in section 12.1.2.2.

Communication Plan(s) should define how information will be disseminated to stakeholders and throughout
the organization, portfolio, and programs. It should also define how and when to communicate and what
mode of communication will be used. The portfolio provides guidance and input to the communications plan
for the programs within the portfolio. Similarly, the program provides guidance and input to the
communications plan for the projects within the program.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 303


14 Escalar Scrum para a Empresa

14.1.2.2 Company Human Resource Plans*

Company Human Resource Plans broadly provide information on when particular personnel will be available
for various projects, programs, and portfolios. They also provide information on plans for hiring personnel
required for future efforts.

14.1.2.3 Stakeholder Analysis

A standard stakeholder analysis is used to identify the stakeholders at the program and portfolio levels.
Further details related to program or portfolio stakeholders may be identified as personas are developed in
the Create and Groom Program or Portfolio Backlog process.

14.1.3 Outputs

14.1.3.1 Minimum Done Criteria*

Described in section 5.4.3.

14.1.3.2 User Story Acceptance Criteria*

Described in section 9.1.3.2.

14.1.3.3 Shared Resources*

Described in section 13.1.3.4.

14.1.3.4 Identified Stakeholders*

Described in section 8.2.3.2.

Key stakeholders at the Portfolio or Program level are an input to this process. Additional stakeholders are
identified in this process.

304 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.1.3.5 Recommended Scrum Guidance Body Improvements

Described in 13.1.3.6.

As a result of the Create Program or Portfolio Components process, suggestions or feedback might be
provided for potential improvements of the Scrum Guidance Body (SGB). These recommended
improvements will be discussed and agreed upon or rejected by the Scrum Guidance Body (see section
14.2, process Review and Update Scrum Guidance Body). If the SGB accepts these suggestions, they will
be incorporated as updates to the Scrum Guidance Body documentation.

14.2 Review and Update Scrum Guidance Body

Figure 14-5 shows all the inputs, tools, and outputs for the Review and Update Scrum Guidance Body
process.

1. Regulations* 1. Members Selection Criteria* 1. Updated Scrum Guidance Body


2. Recommended Scrum Guidance 2. Benchmarking Recommendations*
Body Improvements* 3. Scrum Guidance Body Meetings 2. Actionable Escalations
3. Scrum Guidance Body Members 3. Updated Scrum Guidance Body 12
Members
4. Rejected Updates to the Scrum
Guidance Body
Recommendations

Figure 14-12: Review and Update Scrum Guidance BodyInputs, Tools, and Outputs

Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 305


14 Escalar Scrum para a Empresa

Figure 14-13: Review and Update Scrum Guidance Body Data Flow Diagram

14.2.1 Inputs

14.2.1.1 Regulations*

Regulations include any Federal, Local, State, or industry regulations that the program or portfolio must
adhere to. User Stories created to meet the government regulations within a stipulated time period are
included in the Portfolio or Program Product Backlog.

Sometimes, Scrum Guidance Body recommendations may need to be updated to reflect new regulations.

14.2.1.2 Recommended Scrum Guidance Body Improvements*

Described in section 13.1.3.6.

As a result of Scrum retrospectives and other processes, suggestions and feedback to revise or enhance the
Scrum Guidance Body Recommendations may be made. If the Scrum Guidance Body accepts these
suggestions or feedback, they will be incorporated as updates to the Scrum Guidance Body
Recommendations.

306 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.2.1.3 Scrum Guidance Body Members

The Scrum Guidance Body (SGB) members can include Scrum experts, selected Scrum Masters, Product
Owners and team members (on all levels). However, there should be a limit on the number of members that
a SGB can have in order to ensure that it remains relevant and does not become prescriptive in nature.

14.2.2 Tools

14.2.2.1 Members Selection Criteria*

Members Selection Criteria are created by stakeholders to define the Scrum Guidance Body members, their
roles and responsibilities, the number of members, and their required skills and expertise.

Each company can have its own selection criteria for Scrum Guidance Body members, however, it is
recommended that every member has Scrum expertise and that there is a limit on the number of members
that a SGB can have to ensure that it remains relevant and does not become prescriptive in nature.

14.2.2.2 Benchmarking

An enterprise should regularly benchmark its own practices against other companies in order to keep up with
the competition. Benchmarking is the process of comparing an organizations business processes and
performance metrics to those of leading companies in the same or other industries. 12

14.2.2.3 Scrum Guidance Body Meetings

The Scrum Guidance Body meets regularly to discuss the potential need for an update of the Scrum
Guidance Body Recommendations (e.g., recommended improvements from Retrospectives and other
processes, updated regulations, etc.). The frequency of the meetings is decided by the Scrum Guidance
Body based on the specific needs of the enterprise.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 307


14 Escalar Scrum para a Empresa

14.2.3 Outputs

14.2.3.1 Updated Scrum Guidance Body Recommendations*

Described in 11.2.3.6.

As a result of the review of the Scrum Guidance Body, changes may be necessary and may lead to an
update of the Scrum Guidance Body Recommendations.

14.2.3.2 Actionable Escalations

The Scrum Guidance Body may determine that some company policies do not allow teams to obtain the
maximum benefits from the application of Scrum. In such cases, an escalation should be triggered in order
to expedite approval for a policy change.

14.2.3.3 Updated Scrum Guidance Body Membership

As a result of assessing the Scrum Guidance Body membership, new members may be included in the
Scrum Guidance Body and existing members may be removed or leave the Scrum Guidance Body.

14.2.3.4 Rejected Updates to the Scrum Guidance Body Recommendations

Recommended Scrum Guidance Body Improvements may not always be accepted. If the recommended
improvement is rejected by the Scrum Guidance Body members, an explanation of the reason for the
rejection is provided as feedback to the relevant party.

308 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.3 Create and Groom Program or Portfolio Backlog

Figure 14-7 shows all the inputs, tools, and outputs for the Create and Groom Program or Portfolio Backlog
process.

1. Company Vision and Mission* 1. Prioritized Program or Portfolio 1. Updated Prioritized Program or
2. Prioritized Portfolio Backlog* Backlog Review Meetings* Portfolio Backlog*
3. Prioritized Program Backlog* 2. Communication Techniques* 2. Recommended Scrum Guidance Body
4. Portfolio Product Owner* 3. User Story Prioritization Methods Improvements*
5. Portfolio Scrum Master* 4. User Story Workshop 3. Updated Implementation Deadlines for
6. Program Product Owner* 5. User or Customer Interviews Projects
7. Program Scrum Master* 6. Questionnaires 4. Personas
8. Scrum Guidance Body 5. Identified Risks
Recommendations
9. Company Policies
10. Industry Standards
11. Assessment/Benchmarking Results

12
Figure 14-14: Create and Groom Program or Portfolio BacklogInputs, Tools, and Outputs

Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 309


14 Escalar Scrum para a Empresa

Figure 14-8 shows all the relationship of the Create and Groom Program or Portfolio Backlog process to the
fundamental Scrum processes.

Figure 14-15: Create and Groom Program or Portfolio Backlog Data Flow Diagram

14.3.1 Inputs

14.3.1.1 Company Vision and Mission*

Described in sections 8.1.1.8 and 8.1.1.9.

14.3.1.2 Prioritized Portfolio Backlog*

The Prioritized Portfolio Backlog plays the same role at the portfolio level as the Prioritized Program Backlog
does at a Program level. The items in the Prioritized Portfolio Backlog provide inputs to the various
Prioritized Program Backlogs and ultimately to Prioritized Product Backlogs of individual projects. As
described for Prioritized Program Backlogs in section 8.1.1.5, only minimal, if any, refinement of User Stories
is done at this level, because the refinement is done within the projects at the level of the specific Prioritized
Product Backlogs.

310 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.3.1.3 Prioritized Program Backlog*

Described in section 8.1.1.5.

The Prioritized Program Backlog plays a very similar role at the program level as the Prioritized Product
Backlog does at the project level. It identifies the requirements for the program and their priorities.

There are a few differences, though:

The creation of the respective deliverables and their acceptance is done in the projects of the program. The
done or acceptance criteria for each Product Backlog Item/User story may be defined at the program level.
Projects must adhere to these criteria, but can add their own criteria as required.

The length of a Sprint is project specific and, generally, varies from project to project within a program. In
addition, velocity varies from team to team. Therefore, it is not necessary to have very granular User Stories
at the program level. The refinement of User Stories at the program level goes only far enough to ensure
that the respective story is clearly understood and tangible acceptance criteria for the program can be
defined.

14.3.1.4 Portfolio Product Owner*

Described in section 3.4.4.

The Portfolio Product Owner plays a similar role to that of the Program Product Owner in a program. He or
she is responsible for, and the driver of the creation and the grooming of the Portfolio Product Backlog.
12

14.3.1.5 Portfolio Scrum Master*

Described in section 3.5.3.

In a project, the Program Scrum Master is one of multiple stakeholders. Here, at the Portfolio level, the
Portfolio Scrum Master plays a similar role as the Program Scrum Master does for a program.

14.3.1.6 Program Product Owner*

Described in section 3.4.3.

The Program Product Owner is one of multiple stakeholders in a project. At the program level, the Program
Product Owner plays a similar role to that of the Product Owner in a project. He or she is responsible for and
the driver of the creation and the grooming of the Prioritized Program Product Backlog.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 311


14 Escalar Scrum para a Empresa

14.3.1.7 Program Scrum Master*

Described in section 3.5.2.

The Program Scrum Master is one of the multiple stakeholders in a project. At the program level, the
Program Scrum Master plays a role similar to that of the Scrum Master in a project. He or she is a facilitator,
solves problems, and removes impediments at the program Level.

14.3.1.8 Scrum Guidance Body Recommendations

Described in section 8.1.1.11 and 10.3.1.11.

When creating and grooming a Prioritized Program or Portfolio Backlog, Scrum Guidance Body
Recommendations will provide best practices that should be taken into consideration at the Program or
Portfolio level.

14.3.1.9 Company Policies

Company policies are a set of principles, rules, and guidelines formulated or adopted by an organization.
Changing company policies would affect existing User Stories as they have been created following existing
policies.

14.3.1.10 Industry Standards

New industry standards or changes to existing standards need to be implemented in order to maintain a
viable product or service. Therefore, User Stories related to meeting these standards need to be included in
the Prioritized Program and/or Portfolio Backlog and prioritized accordingly.

Sometimes, Scrum Guidance Body Recommendations need to be changed in order to reflect new or
changed standards.

14.3.1.11 Assessments/Benchmarking Results

First and foremost, assessment/benchmarking results will necessitate an update of the Scrum Guidance
Body Recommendations best practices. The results can also help set a minimum standard when creating a
product or service and lead to changed Done Criteria. Sometimes they may also provide impetus for a
Program or Portfolio Product Owner to develop new User Stories to implement the best practices.

312 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.3.2 Tools

14.3.2.1 Prioritized Program or Portfolio Backlog Review Meetings*

Participation in program or portfolio backlog review meetings is quite different from participation in review
meetings at the project level. Scrum Teams will participate in the grooming sessions at the project level. At
the program or portfolio level, there is representation from each project in the program or from each program
in the portfolio. To streamline the meeting, it is generally recommended to have only one representative from
each project or program attend at the program or portfolio level.

Refer to related sections 10.3.2.1 and 6.5.1.2.

14.3.2.2 Communication Techniques*

Described in section 10.3.2.2.

14.3.2.3 User Story Prioritization Methods

Described in section 8.5.2.1.

At the program or portfolio level, there is normally a smaller number of requirements/User Stories than at the
project level. The percentage of User Stories with a significant tangible value/business need/user impact is
normally much lower than at the project level. Therefore, fewer techniques will be relevant and useful at the 12
program or portfolio level.

For example, Kano analysis has limitations because there wont be any dissatisfiers or exciters. Without a
significant number of stakeholders, especially users, the 100-point method has limited value. The MoSCoW
technique also has limitations because there wont be any nice to have or Wont have features at the
program and portfolio levels.

Paired comparison is a technique that works well at the program and portfolio levels.

14.3.2.4 User Story Workshop

Described in section 8.4.2.2.

Compared to projects, User Story Workshops for programs and portfolios will produce only higher level User
Stories as their outputs, so there will be significantly fewer stories. However, the meetings still provide value
as there will be participation by representatives from different projects in a program or from different
programs in a portfolio. This ensures that requirements are well defined and understood.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 313


14 Escalar Scrum para a Empresa

14.3.2.5 User or Customer Interviews

Described in sections 8.4.2.4.

14.3.2.6 Questionnaires

Described in sections 8.4.2.5.

14.3.3 Outputs

14.3.3.1 Updated Prioritized Program or Portfolio Backlog*

The Prioritized Program or Portfolio Backlog may be updated with new User Stories, new change requests,
new identified risks, updated User Stories, or to reflect reprioritization of existing User Stories.

Refer to related section 10.3.3.1.

14.3.3.2 Recommended Scrum Guidance Body Improvements*

Described in section 13.1.3.6.

As a result of the Create and Groom Program or Portfolio Backlog process, suggestions or feedback might
be provided for potential improvements of the Scrum Guidance Body. These recommended improvements
will be discussed and agreed or rejected by the Scrum Guidance Body (see section 14.2, process Review
and Update Scrum Guidance Body). If the Guidance Body accepts these suggestions, they will be
incorporated as updates to the Scrum Guidance Body documentation.

14.3.3.3 Updated Implementation Deadlines for Projects

Implementation deadlines for projects may be updated to reflect the impact of new or changed User Stories
that need to modify or introduce new requirements.

14.3.3.4 Personas

Described in section 8.4.3.2.

314 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.3.3.5 Identified Risks

Described in section 8.4.3.4.

14.4 Coordinate Program or Portfolio Components

Figure 14-9 shows all the inputs, tools, and outputs for the Coordinate Program or Portfolio Components
process.

1. Definition of Done* 1. Scrum of Scrum (SoS) Meeting* 1. Updated Impediments Logs*


2. Known Dependencies* 2. Scrum of Scrum of Scrums (SoSoS) 2. Updated Dependencies*
3. Prioritized Program or Portfolio Backlog* Meeting 3. Recommended Scrum Guidance Body
4. Portfolio Product Owner* 3. Communication Techniques Improvements
5. Portfolio Scrum Master*
6. Program Product Owner*
7. Program Scrum Master*
8. Potentially Shippable Deliverables from
Projects
9. Impediments Logs
10. Prioritized Product Backlogs
11. Scrum Team Lessons Learned
12. Release Planning Schedules 12

Figure 14-16: Coordinate Program or Portfolio ComponentsInputs, Tools, and Outputs

Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 315


14 Escalar Scrum para a Empresa

Figure 14-10 shows the data flow for the Coordinate Program or Portfolio Components process.

Figure 14-17: Coordinate Program or Portfolio ComponentsData Flow Diagram

14.4.1 Inputs

14.4.1.1 Definition of Done*

Described in section 5.4.2.

Definition of Done defined at the program or portfolio level can be used as minimum Done Criteria for
projects across the enterprise.

14.4.1.2 Known Dependencies*

In case of inter-related projects and/or products within the enterprise, there may be some dependencies that
are identified. Consequently, there should be coordination among projects to manage the dependencies.
These dependencies could include:

Identical Release dates for inter-related projects


Dependencies between Releases
Dependencies on inter-related features

Refer to related sections 9.4.2.3 and 13.1.2.4.

316 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.4.1.3 Prioritized Program or Portfolio Backlog*

Described in sections 14.3.1.2 and 14.3.1.3.

14.4.1.4 Portfolio Product Owner*

Described in sections 3.4.4 and 14.3.1.4.

14.4.1.5 Portfolio Scrum Master*

Described in sections 3.5.3 and 14.3.1.5.

14.4.1.6 Program Product Owner*

Described in sections 3.4.3 and 14.3.1.6.

14.4.1.7 Program Scrum Master*

Described in sections 3.5.2 and 14.3.1.7.


12

14.4.1.8 Potentially Shippable Deliverables from Projects

Potentially Shippable Deliverables from projects are valuable inputs for coordination at the program or
portfolio level. At the end of Sprints in projects, product increments or deliverables are completed. The User
Stories included in these increments meet the Definition of Done criteria as well as their respective
acceptance criteria.

With each completed Sprint in any of the associated projects, it becomes more clear how the respective
projects are progressing. This knowledge not only allows for continuously updated projections regarding
whether or not all projects will meet the required deadlines for certain requirements, but it also provides vital
information needed to deal with the dependencies between projects.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 317


14 Escalar Scrum para a Empresa

14.4.1.9 Impediment Logs

Impediments faced by individual projects can be relevant for other projects. Therefore, Impediment Logs
may need to be shared among projects and/or programs.

Described in section 10.1.1.4. Refer to related section 13.2.1.2 for sharing of impediment logs between
teams in a large project.

14.4.1.10 Prioritized Product Backlogs

Described in section 8.5.3.1.

These would be the Prioritized Product Backlogs at the project level.

14.4.1.11 Scrum Teams Lessons Learned

Described in section 11.2.3.5.

14.4.1.12 Release Planning Schedules

Described in section 8.6.3.1.

These schedules, while tentative and subject to change, are vital to gauge whether or not the respective
projects are likely to meet required deadlines and especially crucial with respect to dependencies.

14.4.2 Tools

14.4.2.1 Scrum of Scrums (SoS) Meeting*

Described in sections 13.2.2.1.

The purpose of this meeting is similar to its use in large projects. At the program level, representatives from
all projects in the program meet at regular intervals in the Scrum of Scrums (SoS) meetings.

318 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.4.2.2 Scrum of Scrum of Scrums (SoSoS) Meeting

At the portfolio level, representatives from all programs and "stand-alone" projects in the portfolio meet at
regular intervals. In attendance would be representatives from the Scrum of Scrums meetings. Therefore,
this additional level of meetings is called Scrum of Scrum of Scrums (SoSoS). Figure 14-11 illustrates the
concept of the Scrum of Scrums (SoS) and the Scrum of Scrum of Scrums Meetings.

Figure 14-18: Scrum of Scrums (SoS) Meeting

In this example, there are six Scrum Teams working simultaneously. Scrum Teams A, B, and C are working
on portions of a program while Scrum Teams D, E, and F are working on portions of another program. A 12
Scrum of Scrums Meeting is held to coordinate the interdependencies between the programs. A Scrum of
Scrums of Scrums Meeting may then be conducted to coordinate and manage dependencies across multiple
or all programs.

14.4.2.3 Communication Techniques

Described in section 10.3.2.2.

Examples of communication techniques that can be used at the program or portfolio level are message
boards and instant messaging.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 319


14 Escalar Scrum para a Empresa

14.4.3 Outputs

14.4.3.1 Updated Impediment Logs*

As a result of the Scrum of Scrums (SoS) or the Scrum of Scrum of Scrums (SoSoS) Meeting, there may be
a need to update the Impediment Logs.

Refer to related section 10.1.1.4.

14.4.3.2 Updated Dependencies*

As a result of coordinating program or portfolio components, there may be need to update the known
dependencies with new dependencies or changes to existing dependencies.

Refer to related sections 9.4.3.3.

14.4.3.3 Recommended Scrum Guidance Body Improvements

Described in section 13.1.3.6.

As a result of the Coordinate Program or Portfolio Components process, suggestions or feedback might be
provided for potential improvements of the Scrum Guidance Body. These recommended improvements will
be discussed and agreed to or rejected by the Scrum Guidance Body (see section 14.2, process Review and
Update Scrum Guidance Body). If the Guidance Body accepts these suggestions, they will be incorporated
as updates to the Scrum Guidance Body documentation.

320 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.5 Retrospect Program or Portfolio Releases

Figure 14-12 shows all the inputs, tools, and outputs for the Retrospect Program or Portfolio Releases
process.

1. Portfolio Product Owner* 1. Retrospect Program or Portfolio 1. Agreed Actionable Improvements*


2. Program Product Owner(s)* Meeting* 2. Assigned Action Items and Due Dates*
3. Portfolio Scrum Master* 2. Scrum Guidance Body Expertise 3. Recommended Scrum Guidance Body
4. Program Scrum Master* Improvements
5. Stakeholders
6. Scrum Guidance Body
Recommendations

Figure 14-19: Retrospect Program or Portfolio ReleasesInputs, Tools, and Outputs

12

Figure 14-20: Retrospect Program or Portfolio ReleasesData Flow Diagram

Note: Asterisks (*) denote a mandatory input, tool, or output for the corresponding process.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 321


14 Escalar Scrum para a Empresa

14.5.1 Inputs

14.5.1.1 Portfolio Product Owner*

Described in sections 3.4.4 and 14.3.1.4.

14.5.1.2 Portfolio Scrum Master*

Described in sections 3.5.3 and 14.3.1.5.

14.5.1.3 Program Product Owner*

Described in sections 3.4.3 and 14.3.1.6.

14.5.1.4 Program Scrum Master*

Described in sections 3.5.2 and 14.3.1.7.

14.5.1.5 Stakeholders

Described in section 3.3.2.

14.5.1.6 Scrum Guidance Body Recommendations

Described in section 8.1.1.11 and 12.2.1.5.

During a retrospective of Program or Portfolio releases, Scrum Guidance Body Recommendations will
provide pertinent best practices including information on administrative procedures, audits, evaluations, and
project transition criteria. This is similar to the role the Scrum Guidance Body Recommendations play at the
project level retrospectives (described in section 12.2.1.5).

322 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


14 Escalar Scrum para a Empresa

14.5.2 Tools

14.5.2.1 Retrospect Program or Portfolio Meeting*

The Retrospect Program or Portfolio Meeting is similar to the Retrospect Project Meeting, described in
12.2.2.1, but is carried out at the program or portfolio level. The major difference is that Retrospect Program
and Portfolio Meetings are held much less frequently than Retrospect Project Meetings.

14.5.2.2 Scrum Guidance Body Expertise

Described in section 8.4.2.7.

14.5.3 Outputs

14.5.3.1 Agreed Actionable Improvements*

Described in section 11.2.3.1.

14.5.3.2 Assigned Action Items and Due Dates*


12
Described in section 11.2.3.2

14.5.3.3 Recommended Scrum Guidance Body Improvements

Described in section 13.1.3.6.

As a result of the Retrospect Program or Portfolio Releases process, suggestions or feedback might be
provided for potential improvements of the Scrum Guidance Body. These recommended improvements will
be discussed and agreed to or rejected by the Scrum Guidance Body (see section 14.2, process Review and
Update Scrum Guidance Body). If the Guidance Body accepts these suggestions, they will be incorporated
as updates to the Scrum Guidance Body documentation.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 323


APNDICE A. VISO GERAL DE GIL

APNDICE A. VISO GERAL GIL

A.1 Introduo
Este apndice pretende familiarizar os leitores com o conceito de desenvolvimento de gil e com as vrias
metodologias geis.

As seguintes sees esto includas:

A.2 Viso GeralEsta seo aborda a definio e os fatores por trs da ascenso de gil.

A.3 Manifesto gilEsta seo apresenta o Manifesto gil, os seus princpios, e A Declarao de
Interdependncia para fornecer o contexto histrico de gil.

A.4 Mtodos geisEsta seo fornece uma viso geral das metodologias especficas de geis,
incluindo:

Lean Kanban
Programao Extrema (XP - eXtreme Programming)
Mtodos de Crystal
Mtodos de Desenvolvimento de Sistemas Dinmicos
Desenvolvimento Orientado a Funcionalidade (FDD - Feature Driven Development)
Desenvolvimento Orientado a Testes (TDD - Test Driven Development)
Desenvolvimento Adaptativo de Software
Processo Unificado gil
Desenvolvimento Orientado a Domnio

324 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE A. VISO GERAL DE GIL

A.2 Viso Geral


O termo "gil" geralmente refere-se a capacidade de se mover ou de responder de forma rpida e fcil; ser
gil. Em qualquer tipo de disciplina de gerenciamento, gil como uma qualidade deve ser um objetivo a ser
alcanado. O gerenciamento gil de projetos, especificamente envolve a capacidade de adaptao durante
a criao de um produto, servio ou outro resultado.

importante compreender que, embora os mtodos de desenvolvimento geis sejam altamente adaptveis,
tambm necessrio considerar a estabilidade nos seus processos adaptativos.

A.2.1 A Ascenso gil

As rpidas mudanas na tecnologia, as exigncias do mercado e as expectativas tornaram cada vez mais
difcil a utilizao de modelos tradicionais de gerenciamento de projetos para o desenvolvimento de
produtos e servios. Isso pavimentou o caminho para a conceituao e implementao de mtodos e
valores geis em muitas organizaes. Os modelos de desenvolvimento geis abordam as deficincias
associadas aos modelos tradicionais de gerenciamento de projetos encontrados no cumprimento das
crescentes exigncias ambientais e as expectativas que as organizaes estavam enfrentando. J que os
modelos tradicionais de gerenciamento de projetos geralmente enfatizam o extenso planejamento inicial, e
de seguir com o projeto de acordo com o plano, tais modelos no foram bem sucedidos em atender as
necessidades reais de um ambiente que sofre mudanas constantemente.

gil depende de planejamento adaptativo, desenvolvimento iterativo e entrega. Concentrando-se


principalmente no valor das pessoas em fazer o trabalho de forma eficaz. Embora metodologias adaptativas
e incrementais existam desde a dcada de 1950, apenas metodologias que estejam em conformidade com
O Manifesto gil so geralmente consideradas como verdadeiramente "geis".

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 325


APNDICE A. VISO GERAL DE GIL

A.3 O Manifesto gil


Em fevereiro de 2001, um grupo de 17 gurus da computao, desenvolvedores de softwares e gerentes,
realizaram um retiro para discutir mtodos leves de desenvolvimento de software. Eles formaram a Aliana
gil e as deliberaes dessas reunies mais tarde resultaram no surgimento do Manifesto do
Desenvolvimento gil de Software. O Manifesto foi escrito por Fowler e Highsmith (2001) e, em seguida,
assinado por todos os participantes para estabelecer as diretrizes bsicas para qualquer metodologia gil.

A finalidade do Manifesto gil foi definida da seguinte forma:

Estamos descobrindo maneiras melhores de desenvolver


software, fazendo-o ns mesmos e ajudando outros a
fazerem o mesmo. Atravs deste trabalho, passamos a valorizar:

Indivduos e Processos e
interaes Ferramentas
Software em Documentao
funcionamento Abrangente
Colaborao com Negociao de
o cliente Contratos
Responder a Seguir um Plano
mudanas

Ou seja, mesmo havendo valor nos itens direita,


valorizamos mais os itens esquerda.
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

Permisso para copiar fornecida pelos autores acima por aviso no site http://agilemanifesto.org/.

326 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE A. VISO GERAL DE GIL

Os quatro valores enfatizados pelo Manifesto gil so elaborados da seguinte forma:

1. Os indivduos e suas interaes acima de procedimentos e ferramentas


Embora os processos e as ferramentas ajudem na concluso com sucesso de um projeto, so os
indivduos que se comprometem, participam, implementam um projeto, e determinam quais
processos e ferramentas sero usados. Os atores-chave em qualquer projeto so, portanto, os
indivduos, por isso a nfase deve ser colocada sobre eles e em suas interaes, ao invs de
processos e ferramentas complicadas.

2. O funcionamento do software acima de documentao abrangente


Embora a documentao seja necessria e til para qualquer projeto, muitos times concentram-se
na coleta e registro de descries qualitativas e quantitativas de entregas, quando o valor real
entregue ao cliente principalmente na forma de software em funcionamento. Portanto, o foco gil
est na entrega de software em funcionamento, em incrementos durante o ciclo de vida do produto,
ao invs de documentao detalhada.

3. A colaborao dos clientes acima da negociao de contratos


Tradicionalmente, os clientes tm sido vistos como jogadores de fora, que esto envolvidos
principalmente no incio e no final do ciclo de vida do produto e cujas relaes esto baseadas em
contratos e em seu cumprimento. gil acredita em uma abordagem de valor compartilhado em que
os clientes so vistos como colaboradores. O time de desenvolvimento e o cliente trabalham em
conjunto para evoluir e desenvolver o produto.

4. A capacidade de resposta mudanas acima de um plano pr-estabelecido


No mercado atual, em que as necessidades dos clientes, as tecnologias disponveis, e os padres
de negcios esto em constante mudana, essencial abordar o desenvolvimento de produtos de
forma adaptativa, permitindo a incorporao de mudana e de desenvolvimento rpido de ciclos
de vida do produto, ao invs de enfatizar o seguimento de planos formados com dados
potencialmente desatualizados.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 327


APNDICE A. VISO GERAL DE GIL

A.3.1 Princpios do Manifesto gil

Os 12 princpios do Manifesto gil por Fowler e Highsmith (2001) so:

1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software
com valor agregado.

2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos


geis tiram vantagem das mudanas visando vantagem competitiva para o cliente.

3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com


preferncia menor escala de tempo.

4. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o


projeto.

5. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio


e confie neles para fazer o trabalho.

6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre um time de


desenvolvimento atravs de conversa cara-a-cara.

7. Software funcionando a medida primria de progresso.

8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores


e usurios devem ser capazes de manter um ritmo constante indefinidamente.

9. Contnua ateno excelncia tcnica e bom design aumenta a agilidade.

10. Simplicidade--a arte de maximizar a quantidade de trabalho no realizado-- essencial.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizados.

12. Em intervalos regulares, o time reflete sobre como se tornar mais eficaz e ento refina e ajusta seu
comportamento de acordo.

328 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE A. VISO GERAL DE GIL

A.3.2 Declarao de Interdependncia

A Declarao de interdependncia do gerenciamento de projetos gil foi escrito no incio de 2005 por um
grupo de 15 lderes de projeto, como suporte ao Manifesto gil. Enumera seis valores de gerenciamento
necessrios para reforar uma mentalidade de desenvolvimento gil, particularmente no gerenciamento de
projetos incertos ou complexos.

A declarao destaca que os times do projeto, clientes e outros stakeholders, so interdependentes e


conectados, e devem reconhecer isto para que sejam bem sucedidos. Os prprios valores tambm so
interdependentes.

Ns ...

aumentamos o retorno do investimento, tornando o fluxo contnuo de valor o nosso


foco.

entregamos resultados confiveis, engajando os clientes em interaes frequentes e


propriedade compartilhada.

esperamos incertezas e gerenciamos levando-as em conta, por meio de iteraes,


antecipao e adaptao.

promovemos criatividade e inovao reconhecendo que os indivduos so a fonte


ltima de valor e criamos um ambiente em que eles fazem a diferena.

impulsionamos o desempenho por meio do compromisso do grupo em obter resultados


e da responsabilidade compartilhada pela eficcia do grupo.

melhoramos a eficcia e a confiabilidade por meio de estratgias situacionais


especficas, processo e prticas.

Anderson. D., Augustine, S., Avery, C., Cockburn, A., Cohn, M., et al. 2005

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 329


APNDICE A. VISO GERAL DE GIL

A.4 Mtodos geis

Uma srie de metodologias geis so originrias e ganharam fora na dcada de 1990 e incio de 2000.
Enquanto diferem-se em vrios aspectos, a sua uniformizao deriva de sua adeso ao Manifesto gil.

The following Agile methods are briefly discussed below:

1. Lean Kanban
2. Programao Extrema (XP - eXtreme Programming)
3. Mtodos de Crystal
4. Mtodos de Desenvolvimento de Sistemas Dinmicos
5. Desenvolvimento Orientado a Funcionalidade (FDD - Feature Driven Development)
6. Desenvolvimento Orientado a Testes (TDD - Test Driven Development)
7. Desenvolvimento Adaptativo de Software
8. Processo Unificado gil
9. Desenvolvimento Orientado a Domnio

A.4.1 Lean Kanban

O conceito de Lean otimiza sistemas de uma organizao para produzir resultados valiosos com base nos
seus recursos, necessidades e alternativas, enquanto reduz o desperdcio. O desperdcio pode ser
resultado da construo da coisa errada, a incapacidade de aprender, ou prticas que impedem o processo.
Como esses fatores so de natureza dinmica, uma organizao lean avalia todo o seu sistema e
continuamente afina seus processos. O fundamento de Lean que a reduo da durao de cada ciclo
(isto , uma iterao) leva a um aumento da produtividade atravs da reduo de atrasos, auxilia na
deteco de erros, numa fase inicial, e consequentemente reduz a quantidade total de esforo necessrio
para terminar uma tarefa. Os princpios de Lean Software tm sido aplicados com sucesso para o
desenvolvimento de software.

Kanban significa, literalmente, uma "placa" ou "outdoor" e defende o uso de recursos visuais para ajudar e
acompanhar a produo. O conceito foi introduzido por Taiichi Ohno considerado o pai dos Sistemas de
Produo Toyota (SPT). O uso de recursos visuais eficaz e tornou-se uma prtica comum. Exemplos
incluem cartas de tarefas, Scrumboards e Grficos Burndown. Estes mtodos ganharam ateno devido
sua prtica na Toyota, lder em gerenciamento de processos. Lean Kanban integra a utilizao dos mtodos
de visualizao, conforme prescrito pelo Kanban, juntamente com os princpios do Lean criando um
processo evolutivo de sistema de gerenciamento progressivamente visual.

330 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE A. VISO GERAL DE GIL

A.4.2 Programao Extrema

Programao Extrema (XP - eXtreme Programming), que se originou na Chrysler Corporation, ganhou fora
na dcada de 1990. XP torna possvel manter o custo de modificar o software sem sofrer aumento radical
com o tempo. Os principais atributos do XP incluem o desenvolvimento incremental, cronogramas flexveis,
cdigos de testes automatizados, comunicao verbal, evoluo constante do design, colaborao estreita,
e assegurando unidades de longo e de curto prazo de todos os envolvidos.

XP valoriza a comunicao, feedback, simplicidade e coragem. Os diferentes papis na abordagem XP


incluem cliente, desenvolvedores, tracker, e treinador. Prescrevendo vrias prticas de codificao,
desenvolvedores, e prticas de negcio, bem como eventos e artefatos para alcanar um desenvolvimento
eficaz e eficiente. XP tem sido amplamente adotado devido s suas prticas de engenharia bem definidas.

A.4.3 Mtodos de Crystal

As metodologias de Crystal de desenvolvimento de software foram introduzidos por Alistair Cockburn no


incio de 1990. Os mtodos de Crystal pretendem ser centrados nas pessoas, leve, e fcil de se adaptar.
Porque as pessoas so primrias, os processos e as ferramentas de desenvolvimento no so fixas, mas
so bastante ajustada s necessidades e caractersticas especficas do projeto. O espectro de cores
usado para decidir sobre a variante de um projeto. Os fatores, tais como o conforto, dinheiro vontade,
dinheiro essencial e vida, desempenham um papel vital na determinao do "peso" da metodologia, que
representada em vrias cores do espectro. A famlia de Crystal dividida em Crystal Transparente, Crystal
Amarelo, Crystal Laranja, Crystal Laranja Web, Crystal Vermelho, Crystal Castanho-avermelhado, Crystal
de Diamante e Crystal de Safira.

Todos os mtodos de Crystal tm quatro papispatrocinador executivo, chefe de designer,


desenvolvedores e usurios experientes. Os mtodos de Crystal recomendam vrias estratgias e tcnicas
para alcanar a agilidade. Um ciclo de projeto Crystal consiste em frete, ciclo de entrega, e embrulho.

A.4.4 Mtodos de Desenvolvimento de Sistemas Dinmicos

O framework dos Mtodos de Desenvolvimento de Sistemas Dinmicos foram inicialmente publicados em


1995 e administrado pelo Consrcio MDSD. O MDSD define qualidade e esforo em termos de custos e
de tempo no incio, e ajusta as entregas do projeto para cumprir os critrios estabelecidos pela priorizao
das entregas nas categorias: "Deve ter", "Deveria ter", "Poderia ter", e "No vai ter" (usando a tcnica de
prioritizao MoSCoW). O DSDM um mtodo de sistema orientado, com seis fases distintasPr-projeto;
Viabilidade; Fundaes; Explorao e Engenharia; Implantao; e Avaliao do Benefcio.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 331


APNDICE A. VISO GERAL DE GIL

A verso mais recente do MDSD conhecido como DSDM Atern, foi introduzido em 2007, centra-se na
priorizao das entregas, e de usurio consistente ou colaborao do cliente. A verso mais recente
inspirada por Arctic Tern, tornando-o um framework de desenvolvimento de software desenvolvedor central
para a entrega de recursos de projetos no prazo e no oramento, com qualidade controlada e de valor para
o usurio.

A.4.5 Desenvolvimento Orientado a Funcionalidade (FDD - Feature Driven


Development)

Desenvolvimento Orientado a Funcionalidade (FDD - Feature Driven Development) foi introduzido por Jeff
De Luca em 1997 e opera com o princpio da concluso de um projeto atravs de sua diviso em pequenas
funes com valor para o cliente, que podem ser entregues em menos de duas semanas. FDD tem dois
princpios centraiso desenvolvimento de software uma atividade humana e o desenvolvimento de
software uma funcionalidade de valor para o cliente.

FDD define seis papis principaisGerente de Projetos, Arquiteto-Chefe, Gerente de Desenvolvimento,


Programadores-chefe, Proprietrios de Classes, e Experts de Domnio com uma srie de papis
coadjuvantes. O processo FDD iterativo e consiste no desenvolvimento de um modelo geral, construindo
uma lista de recursos, e, em seguida, o planejando, designing e construo pelo recurso.

A.4.6 Desenvolvimento Orientado a Testes (TDD - Test Driven Development)

s vezes conhecido como Primeiro Desenvolvimento de Teste, o Desenvolvimento Orientado a Testes foi
introduzido por Kent Beck, um dos criadores da Programao Extrema (XP). O Desenvolvimento Orientado
a Testes um mtodo de desenvolvimento de software que envolve primeiro a escrita do cdigo de teste
automatizado e o desenvolvimento da menor quantidade de cdigo, necessrio para passar naquele teste
mais tarde. Todo o projeto dividido em pequenos recursos, com valor para o cliente, que precisam ser
desenvolvidos no menor ciclo de desenvolvimento possvel. Com base nos requisitos e especificaes dos
clientes, os testes so escritos. Os testes desenvolvidos no estdio anterior so utilizados no design e na
escrita do cdigo de produo.

TDD podem ser classificados em dois nveis: a Aceitao de TDD (ATDD) que exigem um teste de
aceitao, e Desenvolvedor de TDD (DTDD) envolvendo a escrita de um nico desenvolvedor de teste.
TDD tornou-se popular por causa das inmeras vantagens que ele oferece, como por exemplo resultados
rpidos e confiveis, feedback constante, e tempo de depurao reduzido.

332 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE A. VISO GERAL DE GIL

A.4.7 Desenvolvimento Adaptativo de Software

O Desenvolvimento Adaptativo de Software cresceu a partir do trabalho de desenvolvimento rpido de


aplicaes por Jim Highsmith e Sam Bayer. Os destaques do DAS incluem a adaptao constante dos
processos para o trabalho, o fornecimento de solues para os problemas tona em grandes projetos e
desenvolvimento iterativo e incremental com prototipagem contnua.

Ser uma abordagem de desenvolvimento tolerante a mudana e orientada ao risco, o DAS acredita que um
plano no pode admitir incertezas e riscos, pois isso indica um defeito e que o plano falhou. O DAS
baseado em recursos e orientado para o alvo. A primeira fase de desenvolvimento em DAS Especular (ao
contrrio de Planejar), seguido pela Colaborao e fases de Aprendizagem.

A.4.8 Processo Unificado gil

Processo Unificado gil (PUA), evoludo do Processo Unificado Racional, da IBM. Desenvolvido por Scott
Ambler, o PUA combina as tcnicas geis (a indstria provou e testou) como: Desenvolvimento Orientado a
Testes, Modelando gil, gerenciamento de mudanas geis, e refactoring o banco de dados, para entregar
um produto da melhor qualidade em funcionamento.

O PUA, baseia os seus processos e tcnicas sobre os valores da Simplicidade, Agilidade, Personalizao,
Auto-organizao, Independncia de ferramentas, e no foco em atividades de alto valor. Os princpios e
valores do PUA so postos em ao nas fases de Iniciao, Elaborao, Construo e Transio.

A.4.9 Desenvolvimento Orientado a Domnio

O design orientado para o domnio uma abordagem de desenvolvimento gil, com o objetivo de lidar com
projetos complexos, com aplicao vinculada a um modelo em evoluo. Foi concebida por Eric Evans em
2004 e gira em torno do design de um domnio central. "Domnio" definido como uma rea de atividade
em qual o usurio aplica um programa ou funcionalidade. Muitas dessas reas so agrupadas e um modelo
projetado. O modelo consiste num sistema de captaes que pode ser utilizada para a concepo do
projeto geral e resolver os problemas relacionados com os domnios em grupo. Os valores fundamentais do
DOD incluem, domnio orientado, modelo de design orientado, linguagem ubqua, e um contexto delimitado.

Em DOD, a linguagem ubqua estabelecida e o domnio modelado. Em seguida, design,


desenvolvimento e testes de acompanhamento. O refinamento e refactoring do modelo de domnio feito
at que o mesmo seja satisfatrio.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 333


APNDICE C AUTORES E CRTICOS DO GUIA SBOK

APNDICE B. AUTORES E REVISORES DO GUIA SBOK


Este apndice lista os nomes dos indivduos que contriburam para o desenvolvimento e produo do Guia
do SBOK .

SCRUMstudy grata a todos esses indivduos por seu apoio contnuo e reconhece suas contribuies
para o desenvolvimento do Guia do SBOK .

B.1 Autor Principal


Tridibesh Satpathy

B.2 Co-Autores e Especialistas no Assunto

R-A Alves
Winfried Hackmann
Quincy D. Jordan
Gaynell Malone
J. Drew Nations
Buddy Peacock
Karen Lyncook
Jaimie M. Rush
Elizabeth Lynne Warren
Ruth Kim
Mehul Doshi
Gaurav Garg
Ajey Grandhem
Sayan Guha
Vinay Jagannath
Deepak Ramaswamy
Ahmed Touseefullah Siddiqui

334 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE B AUTORES E CRTICOS DO GUIA SBOK

B.3 Revisores e Time de Edio

Corey T. Bailey
Sohini Banerjee
Vince Belanger
Bobbie Green
Magaline D. Harvey
Ravneet Kaur
Robert Lamb
Mimi LaRaque
Melissa Lauro
Richard Mather
Lachlan McGurk
Madhuresh Kumar Mishra
Neha Mishra
Yogaraj Mudalgi
Jose Nunez
Obi Nwaojigba
Bryan Lee Perez
James Pruitt
Charles J. Quansah
Frank Quinteros
Nadra Rafee
Tommie L. Sherrill
Barbara Siefken
Sandra A. Strech
Frances Mary Jo Tessler
Chrys Thorsen
Mike Tomaszewski
Ron Villmow
Josemari Wilson (Tradutora)
Geraldo B. Farias (Editor da verso em Portugus)

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 335


APNDICE C AUTORES E CRTICOS DO GUIA SBOK

APPENDIX C. THIRD EDITION UPDATES


This appendix provides a summary of updates implemented in the SBOKTM GuideThird Edition as
compared to the previous edition.

C.1 Summary of Changes


The scope of updates made for the SBOKTM GuideThird Edition primarily focused on the following major
areas:
Improved and expanded description of roles and responsibilities in the Scrum Framework,
particularly as they relate to large projects, programs, and portfolios.
Clarification and streamlining of the processes identified for the Plan and Estimate phase. This
included simplification of the meetings involved in these processes.
Additional content covering how to scale Scrum for large projects and at the enterprise level.
General improvements were also made throughout the text to ensure information was accurate, clear, and
complete. This included updates to tables and figures as appropriate.

C.2 Third Edition Updates by Chapter

Chapter Key Changes Made


1 Improved consistency and clarity.
Added reference to two new certifications, SSMCTM and SSPOCTM (section 1.3).
Updated Scrum Processes (section 1.4.4) to reflect new process names for Plan and
Estimate phase (see Chapter 9). Also, added the processes discussed in Chapters 13 and
14 for Scaling Scrum for Large Projects and Scaling Scrum for the Enterprise.
2 Simplified the verbiage for the Three Daily Questions in the Conduct Daily Standup
process to be more generic to meeting time of day (section 2.7.1)
Provided more detailed description of Sprint Planning Meeting (section 2.7.1)
3 In general, this chapter was restructured to consolidate the descriptions of roles and
responsibilities under the core Scrum roles: Product Owner (section 3.4), Scrum Master
(section 3.5) and Scrum Team (section 3.6). This includes expanded definitions, particularly
for roles related to large projects, programs and portfolios.
Summary of Responsibilities (section 3.8) updated to include Chief Product Owner and Chief
Scrum Master roles.

336 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


APNDICE B AUTORES E CRTICOS DO GUIA SBOK

Chapter Key Changes Made


4 Summary of Responsibilities (section 4.8) updated to include Chief Product Owner and Chief
Scrum Master roles.
5 Improved description of Definition of Done (section 5.4.2) and Minimum Done Criteria
(section 5.4.3)
Summary of Responsibilities (section 5.6) updated to include Chief Product Owner and Chief
Scrum Master roles.
6 Summary of Responsibilities (section 6.7) updated to include Chief Product Owner and Chief
Scrum Master roles.
7 Summary of Responsibilities (section 7.7) updated to include Chief Product Owner and Chief
Scrum Master roles.
8 Moved descriptions for Program Product Owner and Program Scrum Master to Chapter 3 for
consistency.
Minor changes to update terminology and figures to match updates made in other chapters.
9 The Approve, Estimate and Commit User Stories process was replaced by the following
two processes: Estimate User Stories (section 9.2) and Commit User Stories (section
9.3). This was done to provide improved clarity to the inputs, tools and outputs relevant to
the activities performed in these processes.
A new tool, Estimation Methods was defined to consolidate many of the estimation
techniques called out individually in the previous edition (section 9.2.2.3, 9.5.2.3).
The Create Tasks process was renamed to Identify Tasks (section 9.4), to clarify that
tasks are defined or identified based on the previously Committed User Stories.
Inputs, tools and outputs for all the processes in the Plan and Estimate phase were
evaluated and adjusted for correctness.
10 The verbiage for the Three Daily Questions in the Conduct Daily Standup process was
updated to be more generic to meeting time of day (section 10.2.2.2).
Minor changes to update terminology and figures to match updates made in other chapters.
11 Removed Convene Scrum of Scrums process. This is now addressed in Chapter 13,
Scaling Scrum for Large Projects.
Minor changes to update terminology and figures to match updates made in other chapters.
12 Minor changes to update terminology and figures to match updates made in other chapters.
13 Scaling Scrum for Large Projects entire chapter added as new content.
14 Scaling Scrum for the Enterprise entire chapter added as new content.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 337


REFERNCIAS

REFERNCIAS
Anderson, D., Augustine, S., Avery, C., Cockburn, A., Cohn, M., DeCarlo, D., Fitzgerald, D., Highsmith, J.,
Jepsen, O., Lindstrom, L., Little, T., McDonald, K., Pixton, P., Smith, P., e Wysocki, R. (2005) Declaration of
Interdependence, acessada em Setembro de 2013, http://www.pmdoi.org/.

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J.,
Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland,
J., and Thomas, D. (2001) Manifesto for Agile Software Development, acessada em Setembro de 2013,
http://agilemanifesto.org/.

Fellers, G. (1994) Why Things Go Wrong: Deming Philosophy In A Dozen Ten-Minute Sessions. Gretna, LA:
Pelican Publishing.

Greenleaf, R. K. (1977) Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness.
Mahwah, NJ: Paulist Press.

Kano, N., Seraku, N., Takahashi, F., and Tsuji, S. (1984) Attractive Quality and Must Be Quality. Quality,
14 (2): 3948.

Leffingwell, D. and Widrig, D. (2003) Managing Software Requirements: A Use Case Approach, 2nd ed.
Boston: Addison-Wesley.

Maslow, A. H. (1943) A Theory of Human Motivation. Psychological Review, 50 (4): 370396.

McGregor, D. (1960) The Human Side of Enterprise. New York: McGraw-Hill.

Patton, J. (2005) Its All in How You Slice. Better Software, January: 1640.

Spears, L. C. (2010) Character and Servant Leadership: Ten Characteristics of Effective, Caring Leaders.
The Journal of Virtues & Leadership, 1 (1): 2530.

Takeuchi, H. and Nonaka, I. (1986) The New New Product Development Game. Harvard Business Review,
JanuaryFebruary: 137146.

338 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


REFERNCIAS

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 339


GLOSSRIO

GLOSSRIO

Adaptao

A Adaptao acontece quando o Time Central do Scrum e o(s) Stakeholder(s) aprendem atravs da
transparncia e inspeo, e em seguida, fazem adaptaes em seu trabalho atravs de melhorias.

Ameaas

As ameaas so os riscos que podem afetar o projeto de forma negativa.

Anlise de Gap

A Anlise de Gap uma tcnica usada para comparar o estado atual, real, com o estado desejado, e
determinar como fazer a ponte de ligao entre eles.

Anlise de Kano

A Anlise de Kano foi desenvolvida por Noriaki Kano (1984), com base nas preferncias dos clientes, esta
anlise envolve a classificao de caractersticas ou requisitos em quatro categorias:

1. Excitantes/Prazerosos
2. Satisfatrios
3. Insatisfatrios
4. Indiferentes

Anlise de Pareto

Essa tcnica de avaliao de risco envolve a classificao de riscos por magnitude, ajudando o Time Scrum
a direcionar os riscos, na ordem de seus possveis impactos sobre o projeto.

Anlise de Valor Agregado

A Anlise de Valor Agregado analisa o desempenho real do projeto, em relao ao desempenho planejado
em um determinado ponto. Mede as variaes atuais no cronograma e no custo de desempenho do projeto,
e com base no desempenho atual determinado, prev o custo final do projeto.

340 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Anlise SWOT

A Anlise SWOT uma abordagem estruturada para o planejamento do projeto, que ajuda a avaliar os
pontos fortes e fracos, as oportunidades e as ameaas, relacionadas a um projeto. Este tipo de anlise
ajuda a identificar os fatores internos e externos que possam afetar o projeto.

Apetite de Risco

O Apetite de Risco refere-se a quantidade de incerteza que um stakeholder ou uma organizao est
disposta a assumir.

Aprovar, Estimar, e Comprometer as Estrias de Usurio

Nesse processo, o Dono do Produto aprova as Estrias de Usurio para o Sprint. Em seguida, o Scrum
Master e o Time Scrum estimam os esforos necessrios para desenvolver a funcionalidade descrita em
cada Estria de Usurio. Por fim, o Time Scrum se compromete a entregar os requisitos do cliente sob a
forma de Estrias de Usurio aprovadas, estimadas, e comprometidas.

rvores de Probabilidade

Os eventos potenciais so representados em um diagrama com um ramo para cada resultado possvel dos
eventos. A probabilidade de cada resultado indicado no ramo apropriado, sendo que esses valores podem
ser usados para calcular o impacto geral de ocorrncia de risco em um projeto.

Atitude de Risco

Essencialmente, a Atitude de Risco do(s) Stakeholder(s) determina quanto risco o(s) Stakeholder(s)
considera aceitvel. Esse um fator determinante quando decidem tomar aes para atenuar potenciais
riscos adversos.

Auto-organizao

O Scrum acredita que os colaboradores so auto-motivados e buscam aceitar maior responsabilidade.


Sendo assim, eles entregam muito mais valor quando auto-organizados.

Avaliao de Risco

A Avaliao de Risco refere-se a avaliar e estimar os riscos identificados.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 341


GLOSSRIO

Averso a Riscos

Averso a Riscos uma das categorias de Funo de Utilidade. Refere-se ao Stakeholder no estando
disposto a aceitar um risco, independentemente do benefcio ou oportunidade.

Backlog do Produto do Programa Atualizado

O Backlog do Produto do Programa que sofre preparaes peridicas para incorporar as mudanas e as
novas exigncias.

Backlog do Sprint

O Backlog do Sprint uma lista de tarefas a serem executadas pelo Time Scrum no prximo Sprint.

Backlog Priorizado do Produto

O Backlog Priorizado do Produto um documento de requisitos individuais que definem o escopo do


projeto, fornecendo uma lista de prioridades das caractersticas do produto ou servio a serem entregues
pelo projeto.

Benefcios do Projeto

Os Benefcios do Projeto incluem todas as melhorias mensurveis em um produto, servio ou resultado que
podem ser fornecidas na concluso bem sucedida de um projeto.

Brainstorming

So sesses onde os stakeholders e os membros do Time Central do Scrum, abertamente dividem idias
atravs de debates e sesses de compartilhamento de conhecimento, que normalmente so conduzidos
por um facilitador.

Buscando o Risco

Buscando o Risco uma das categorias de Funo de Utilidade que se refere a disposio do stakeholder
em aceitar o risco, mesmo que este proporcione uma margem de aumento em retorno ou benefcio para o
projeto.

Calendrio do Time

O Calendrio do Time contm informaes sobre a disponibilidade dos membros do time, inclundo
informaes relacionadas a frias, afastamentos, eventos importantes, e feriados.

342 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Cartas de ndice

As Cartas de ndice, muitas vezes descritas como Cartas da Estria, so usadas para rastrear as Estrias
de Usurio durante todo o projeto. Isso aumenta a visibilidade e transparncia e facilita a deteco precoce
de eventuais problemas que possam surgir.

Checklists de Risco

Checklists de Risco incluem os pontos-chave a serem considerados na identificao dos riscos, os riscos
comuns encontrados em projetos Scrum, ou at mesmo as categorias de riscos que devem ser abordadas
pelo time.

Ciclo PDCA/PDSA

O Ciclo Plan-Do-Check-Act (Planejar-Executar-Verificar-Agir)tambm conhecido como o Ciclo Deming ou


Shewhartfoi desenvolvido pelo Dr. W. Edwards Deming, considerado o pai do controle de qualidade
moderno e Dr. Walter A. Shewhart. Deming mais tarde modificou o ciclo Plan-Do-Check-Act para Plan-Do-
Study-Act (Panejar-Executar-Estudar-Agir), porque ele considerou que o termo "Estudar", enfatiza a anlise,
ao invs de simplesmente inspeo, como sugere o termo "Verificar". Tanto Scrum quanto o Ciclo Deming/
Shewhart/ PDCA so mtodos iterativos que se concentram na melhoria contnua.

Cliente

O Cliente um indivduo ou uma organizao que adquire o produto, servio ou outro resultado do projeto.
Para qualquer organizao, dependendo do projeto, podem haver clientes internos (dentro da mesma
organizao) ou externos (fora da organizao).

Clientes-Alvo para as Releases

Nem todos os lanamentos tero como alvo todos os stakeholders ou usurios. Os Stakeholders podem
optar por limitar certos lanamentos para um subconjunto de usurios. O Plano da Release especifica os
Clientes-Alvo para as Releases.

Colaborao

A Colaborao em Scrum refere-se ao Time Central do Scrum trabalhando em conjunto e interagindo com
os stakeholders, para criar e validar as entregas do projeto para atingir os objetivos delineados na Viso do
Projeto. A colaborao ocorre quando uma time trabalha em conjunto para agregar valor as contribuies
de cada indivduo, produzindo algo maior.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 343


GLOSSRIO

Colocation

Colocation ter todos os membros do Time Central do Scrum localizados no mesmo local de trabalho,
aproveitando as vantagens de uma melhor coordenao, resoluo de problemas, compartilhamento de
conhecimento e aprendizagem.

Comparao Pareada

A Comparao pareada uma tcnica onde uma lista de todas as Estrias de Usurio no Backlog
Priorizado do Produto preparada. Em seguida, cada Estria de Usurio comparada individualmente com
as outras Estrias de Usurio da lista, um de cada vez. Cada vez que duas Estrias de Usurio so
comparadas, tomada uma deciso em relao a qual das duas mais importante. Atravs deste
processo, uma lista priorizada de Estrias de Usurio pode ser gerada.

Comunicao de Risco

A Comunicao de Risco envolve a comunicao dos resultados das quatro primeiras etapas de
Gerenciamento de Risco ao(s) Stakeholder(s) apropriado(s), e a determinao de sua percepo sob os
eventos incertos.

Conduzir a Reunio Diria

Conduzir a Reunio Diria um processo no qual, uma reunio Time-boxed e altamente focada realizada
todos os dias. Esta reunio chamada de Reunio Diria, um frum para o Time Scrum com a
oportunidade de atualizar uns aos outros sobre o seu progresso e quaisquer impedimentos que possam
estar enfrentando.

Conduzir o Planejamento da Relase

Nesse processo, o Time Central do Scrum analisa as Estrias de Usurio de alto nvel no Backlog
Priorizado do Produto para desenvolver um Cronograma de Planejamento da Release, que
essencialmente, um cronograma de implantao por fases que pode ser compartilhado com o
Stakeholder(s). O tamanho dos Sprints tambm determinado durante esse processo.

Contedo da Release

composto por informaes essenciais sobre as entregas que podem ajudar o Time de Suporte ao Cliente.

344 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Contrato de Desenvolvimento em Fases

Esse contrato assegura a disponibilizao de fundos a cada ms ou a cada trimestre, aps a concluso
com xito de um lanamento. Incentiva tanto o cliente como o fornecedor e garante que o risco monetrio
do cliente seja limitado a esse determinado perodo de tempo, j que os lanamentos fracassados no so
financiados.

Contrato de Entrega Incremental

Este contrato inclui pontos de inspees em intervalos regulares, ajudando o cliente ou os stakeholders a
tomarem decises sobre o desenvolvimento do produto periodicamente ao longo do projeto, em cada ponto
de inspeo. O cliente pode aceitar o desenvolvimento do produto, optar por parar o seu desenvolvimento,
ou solicitar modificaes.

Contrato de Incentivo e Penalidade

Esse contrato baseia-se no acordo de que o fornecedor ser recompensado com um incentivo financeiro,
se os produtos do projeto forem entregues no tempo, mas incorrer em sanes financeiras, se a entrega
estiver atrasada.

Contrato de Prestaes de Trabalho

Os Entregveis que atendam os Critrios de Aceitao recebem formalmente a assinatura de concluso de


negcio e a aprovao pelo cliente ou patrocinador.

Contrato Joint Venture

Este contrato geralmente usado quando duas ou mais partes formam uma parceiria para a realizao do
trabalho de um projeto. Ambas as partes envolvidas no projeto recebero Retorno sobre Investimento,
porque os rendimentos ou benefcios gerados sero compartilhados entre todas as partes.

Controle de Processos Empricos

Um modelo de Controle de Processos Empricos ajuda nas tomadas de decises baseadas em observao
e experimentao, ao invs de planejamento inicial detalhado. Ele se baseia em trs ideias principais:
transparncia, inspeo e adaptao.

Controle de Qualidade

O Controle de Qualidade refere-se execuo das atividades de qualidade planejadas pelo Time Scrum, no
processo de criao das entregas que so potencialmente utilizveis. Tambm inclui aprender a partir de
cada conjunto de atividades concludas, a fim de alcanar a melhoria contnua.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 345


GLOSSRIO

Convocar o Scrum de Scrums

Neste processo, o(s) Scrum Master(s) ou os representantes do Time Scrum so convocados para a
Reunio do Scrum de Scrums, que ocorre em intervalos predeterminados, ou sempre que necessrio, para
colaborar e acompanhar seus respectivos avanos e impedimentos, e dependncias entre os times.

Coordenao Melhor do Time

A reunio do Scrum de Scrums facilita a coordenao do trabalho entre vrios Times Scrum. Isso
especialmente importante quando h tarefas que envolvem dependncias inter-time. As incompatibilidades
e discrepncias entre o trabalho e as entregas de diferentes times so rapidamente expostas. Esse frum
tambm oferece aos times a oportunidade de demonstrar suas realizaes e de dar feedback para os
outros times.

Criar a Viso do Projeto

Neste processo, o Caso de Negcio do Projeto revisado para criar uma Declarao da Viso do Projeto,
que servir de inspirao e orientao para todo o projeto. O Dono do Produto identificado nesse
processo.

Criar as Estrias de Usurio

Nesse processo, as Estrias de Usurio e os Critrios de Aceitao da Estria de Usurio so criados. As


Estrias de Usurio so geralmente escritas pelo Dono do Produto e so projetadas para assegurar que os
requisitos do cliente sejam claramente descritos e possam ser totalmente compreendidos por todos os
stakeholders.

Criar as Tarefas

Nesse processo, as Estrias de Usurio Aprovadas, Estimadas, e Comprometidas, so divididas em tarefas


especficas, e transformadas em uma Lista de Tarefas. Muitas vezes, uma Reunio de Planejamento de
Tarefas realizada para este fim.

Criar os Entregveis

Criar os Entregveis o processo em que o Time Scrum trabalha nas tarefas no Backlog do Sprint para
criar os Entregveis do Sprint.

Criar o Backlog do Sprint

Neste processo, o Time Central do Scrum organiza uma Reunio de Planejamento do Sprint, onde o grupo
cria um Backlog do Sprint contendo todas as tarefas a serem concludas no Sprint.

346 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Criar o Backlog Priorizado do Produto

Neste processo, os picos so refinados e elaborados, e em seguida priorizados, para criar o Backlog
Priorizado do Produto para o projeto. Os Critrios de Pronto tambm so estabelecidos neste ponto.

Critrios de Aceitao da Estria de Usurio

Cada Estria de Usurio se associa com os Critrios de Aceitao. As Estrias de Usurio so subjetivas,
por tanto, os Critrios de Aceitao fornecem a objetividade necessria para a Estria de Usurio ser
considerada Pronta ou no Pronta durante a Reviso do Sprint, proporcionando um entendimento melhor
para o time sobre o que se espera de uma Estria de Usurio.

Critrios de Estimativa

O objetivo principal da utilizao de Critrios de Estimativa, o de manter os tamanhos de estimativa


relativos e minimizar a necessidade de re-estimao. Os Critrios de Estimativa podem ser expressos de
vrias maneiras, tendo com dois exemplos comuns, os pontos da estria e o tempo ideal.

Critrios de Pronto

Os Critrios de Pronto so um conjunto de regras aplicveis a todas as Estrias de Usurio. muito


importante ter uma definio clara de Pronto, porque o mesmo, remove a ambiguidade dos requisitos e
ajuda o time a aderir s normas de qualidade obrigatrias. Esta definio clara usada para criar os
Critrios de Pronto que so uma sada do processo de Criar o Backlog Priorizado do Produto. Uma Estria
de Usurio considerada Pronta, aps sere demonstrada e aprovada pelo Dono do Produto, que a julga
com base nos Critrios de Pronto e nos Critrios de Aceitao da Estria de Usurio.

Critrios Mnimos de Aceitao

Os Critrios Mnimos de Aceitao so declarados pela unidade de negcios. Em seguida, passam a fazer
parte dos Critrios de Aceitao para qualquer Estria de Usurio, para essa unidade de negcios.
Qualquer funcionalidade definida pela unidade de negcios, se precisar ser aceita pelo respectivo Dono do
Produto, deve satisfazer estes Critrios Mnimos de Aceitao.

Cronograma de Planejamento da Release

Um Cronograma de Planejamento da Release um dos principais resultados do processo de Conduzir o


Planejamento da Release. Afirma quais entregveis devem ser lanadas para os clientes, juntamente com
os intervalos planejados e as datas para o lanamento. Pode ser que no haja um lanamento agendado no
final de cada iterao do Sprint.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 347


GLOSSRIO

Custo de Oportunidade

O custo de oportunidade refere-se ao valor da prxima melhor opo de negcio ou projeto que foi
descartado em favor do projeto escolhido.

Custos do Projeto

So investimentos e outros custos de desenvolvimento de um projeto.

Declarao da Viso do Projeto

A Declarao da Viso do Projeto bem estruturada o resultado principal do processo de Criar a Viso do
Projeto. Uma boa Viso do Projeto explica as necessidades do negcio e o que o projeto se destina a
atender, ao invs de explicar como ele vai atender estas necessidades.

Decomposio

A Decomposio a ferramenta utilizada na diviso de tarefas de altos nveis, em tarefas mais detalhadas,
de nveis mais baixos. As Estrias de Usurio so separadas em tarefas pelos membros do Time Scrum. As
Estrias de Usurio no Backlog Priorizado do Produto devem ser suficientemente separadas em um nvel
em que possam fornecer informaes adequadas ao Time Scrum, para que o time crie entregas de Tarefas
mencionadas na Llista de Tarefas.

Demonstrar e Validar o Sprint

Neste processo, o Time Scrum demonstra as Entregas do Sprint para o Dono do Produto e para os
stakeholders durante uma Reunio de Reviso do Sprint.

Dependncias Discricionrias

As Dependncias Discricionrias so dependncias que so colocadas no fluxo de trabalho por opo.


Normalmente, as dependncias discricionrias so determinadas pelo Time Scrum, com base em
experincias passadas ou em melhores prticas sobre um assunto ou domnio.

Dependncias Externas

As Dependncias Externas so aquelas relacionadas a tarefas, atividades ou produtos que esto fora do
escopo de trabalho a ser executado pelo Time Scrum, mas que so necessrias para completar uma tarefa
ou criar um entregvel do projeto. As Dependncias Externas esto geralmente fora do controle do Time
Scrum.

348 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Dependncias Internas

As Dependncias Internas so aquelas dependncias entre tarefas, produtos ou atividades, que esto sob
o controle do Time Scrum e no mbito do trabalho a ser executado pelo Time Scrum.

Dependncias Obrigatrias

Essas dependncias so inerentes natureza do trabalho, como uma limitao fsica, e podem ser devidas
a obrigaes contratuais ou requisitos legais.

Desenvolver os picos

Nesse processo, a Declarao da Viso do Projeto serve como base para o desenvolvimento dos picos.
Reunies dos Grupos de Usurios podem ser realizadas para Desenvolver os picos.

Determinao de Dependncia

Uma vez que o Time Scrum tenha selecionado as Estrias de Usurio para um determinado Sprint, os
membros do time devem ento considerar qualquer dependncia, incluindo as relacionadas com a
disponibilidade de pessoal, assim como qualquer dependncia tcnica. Documentar devidamente as
dependncias, ajuda o Time Scrum a determinar a ordem relativa em que as tarefas devem ser executadas
para criar as Entregas do Sprint. As dependncias tambm destacam a relao e interao entre tarefas,
ambos dentro do Time Scrum trabalhando em um determinado Sprint, com em outros Times Scrum do
projeto.

Diagrama de Fluxo Cumulativo (DFC)

Um Diagrama de Fluxo Cumulativo (DFC) uma ferramenta til na elaborao de relatrios e


acompanhamento de desempenho do projeto. Ele fornece uma representao visual simples do andamento
do projeto, em um determinado ponto. normalmente usado para fornecer um status de nvel superior, de
todo o projeto, e no de atualizaes dirias para os Sprints individuais.

Dimensionamento Relativo/ Pontos de Estria

Alm de serem usados para estimar os custos, os Pontos de Estria tambm podem ser usados para
estimar o tamanho total de uma Estria de Usurio ou recurso. Esta abordagem atribui um valor de ponto
de estria, baseado em uma avaliao geral do tamanho de uma Estria de Usurio levando em
considerao o risco, a quantidade de esforo exigido e o nvel de complexidade.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 349


GLOSSRIO

Dinheiro Monopoly

O Dinheiro Monopoly uma tcnica que consiste em dar ao cliente "dinheiro monopoly" ou "dinheiro falso",
igual ao montante do oramento do projeto e pedindo-lhes para distribu-lo entre as Estrias de Usurio em
questo. Desta forma, o cliente vai priorizar com base no que eles esto dispostos a pagar por cada Estria
de Usurio.

Dvida Tcnica

A Dvida Tcnica (tambm referida como dvida de design ou dvida de cdigo) refere-se ao trabalho que os
times classificam com prioridade inferior, omitente ou como no completado, j que eles trabalham
primeiramente na criao dos principais entregveis associados com o produto do projeto. A Dvida Tcnica
acumula e deve ser paga no futuro.

Dono do Produto

O Dono do Produto a pessoa responsvel por maximizar o valor de negcio para o projeto. Sendo
tambm a pessoa responsvel por articular as necessidades dos clientes e manter a justificativa de negcio
para o projeto.

Dono do Produto Chefe

No caso de grandes projetos, o Dono do Produto Chefe prepara e mantm todo o Backlog Priorizado do
Produto para o projeto, e coordena o trabalho entre os Donos do Produto dos Times Scrum. Os Donos do
Produto, por sua vez, gerenciam suas respectivas partes do Backlog Priorizado do Produto.

Dono do Produto do Portflio

O Dono do Produto do Portflio define os objetivos estratgicos e as prioridades para o portflio.

Dono do Produto do Programa

O Dono do Produto do Programa define os objetivos estratgicos e as prioridades para o programa.

Durao do Sprint

Com base em vrias entradas, incluindo os requisitos de negcio e o Cronograma de Planejamento da


Release, o Dono do Produto e o Time Scrum decidem sobre a durao dos Sprints para o projeto. Uma vez
determinada, a durao do Sprint normalmente fixada para o projeto.

350 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Entrega Iterativa

A Entrega Iterativa a entrega de valor para o cliente em fases.

Entregveis do Sprint

Os Entregveis do Sprint referem-se a incrementos de produtos ou entregveis que so concludos no final


de cada Sprint.

Entregveis em Funcionamento

Esta sada o envio final do entregvel para o qual o projeto foi sancionado.

Entregveis Rejeitados

So os entregveis que no atendem aos Critrios de Aceitao definidos. A lista de Entregveis


Rejeitados mantida e atualizada aps cada Reunio de Reviso do Sprint com quaisquer produtos que
no foram aceitos.

Entregvel Aceito

Os entregveis finais que satisfaam os Critrios de Aceitao da Estria de Usurio so aceitos pelo Dono
do Produto. So considerados Entregveis Aceitos os que podem ser liberados para o cliente, se assim o
desejarem.

Envio de Entregveis

Nesse processo, os Entregveis Aceitos esto em transio ou so entregues ao Stakeholder(s) relevantes.


Um Acordo de Entregveis em Funcionamento, documenta a concluso bem-sucedida do Sprint.

picos

Os picos so escritos nas fases iniciais do projeto, quando a maioria das Estrias de Usurio so
funcionalidades de alto nvel ou descries de produtos, e quando os requisitos so amplamente definidos.
So Estrias de Usurio grandes e no refinadas no Backlog Priorizado do Produto.

Escopo

O Escopo de um projeto a soma total de todos os incrementos do produto e do trabalho necessrio para o
desenvolvimento do produto final.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 351


GLOSSRIO

Escrevendo Expertises da Estria de Usurio

O Dono do Produto, com base na sua interao com os stakeholders, expertise e conhecimento prprio do
negcio e inputs do time, desenvolve Estrias de Usurio que formam o Backlog Priorizado do Produto
inicial para o projeto.

Esquemas Simples

Os Esquemas Simples envolvem a rotulagem de itens, como prioridade "1", "2", "3" ou "Alta", "Mdia" e
"Baixa" e assim por diante. Embora esta seja uma abordagem simples e direta, ela pode tornar-se
problemtica, porque muitas vezes h uma tendncia a se rotular todos os itens como prioridade "1" ou
"Alta".

Estimativa de Afinidade

A Estimativa de Afinidade uma tcnica usada para estimar rapidamente um grande nmero de Estrias de
Usurio, usando categorias. As categorias podem ser pequenas, mdias ou grandes, ou podem ser
numeradas usando valores de ponto da estria para indicar seu tamanho relativo. Alguns dos benefcios
principais dessa abordagem, esto no fato de que o processo muito transparente, visvel para todos, e
fcil de ser conduzido.

Estimativa de Intervalo

As estimativas para os projetos devem ser apresentadas em intervalos. Nmeros exatos podem dar a
impresso de serem altamente precisos, quando na verdade podem no ser. De fato, as estimativas, por
definio, so entendidas como no sendo exatamente precisas. A Estimativa de Intervalo deve ser
baseada no nvel de confiana que o time tem em cada estimativa.

Estrias de Usurio

As Estrias de Usurio aderem uma estrutura especfica pr-definida, uma maneira simples de documentar
os requisitos e desejos, as funcionalidades para o usurio final. Os requisitos expressos nas Estrias de
Usurio so declaraes curtas, simples e fceis de entender, resultando em uma melhor comunicao
entre os stakeholders, e em melhores estimativas pelo time.

Estrias de Usurio Aprovadas, Estimadas, e Comprometidas

As Estrias de Usurio so entradas para esse processo, que tem estimativas de altos nveis decorrentes
dos processos de Criar o Backlog Priorizado do Produto e de Criar as Estrias de Usurio. Essas
estimativas so utilizadas pelo Dono do Produto, para aprovar as Estrias de Usurio para o Sprint. Uma
vez aprovadas, as Estrias de Usurio so estimadas pelo time atravs de diferentes tcnicas de
estimativa. Aps a estimativa, o time se compromete um subconjunto das Estrias de Usurio aprovadas

352 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

e estimadas, que eles acreditam que podem completar no prximo Sprint. Essas Estrias de Usurio so
Aprovadas, Estimadas, e Comprometidas, e se tornaro parte do Backlog do Sprint.

Estrutura Analtica de Risco

Nesta estrutura, os riscos so agrupados de acordo com suas categorias ou semelhanas. Por exemplo, os
riscos podem ser categorizados como financeiros, tcnicos, ou relacionados a segurana.

Estudo de Mercado

O Estudo de Mercado refere-se pesquisa, coleta, comparao e anlise organizada de dados,


relacionadas com as preferncias dos clientes para com os produtos. Muitas vezes, inclui dados extensos
sobre as tendncias de mercado, segmentao de mercado e processos de marketing.

Etapa de Normatizao

A terceira fase da formao do time, quando o time comea a amadurecer, a resolver as suas diferenas
internas, e a encontrar solues para trabalhar em conjunto. considerado um perodo de adaptao.

Etapa de Realizao

A etapa final da formao do time, quando o time se torna mais coeso e atua em seu nvel mais alto em
termos de desempenho. Os membros evoluem em um time de profissionais eficientes que so
consistentemente produtivos.

Etapa Tempestade

A segunda etapa de formao do time, onde o time comea a tentar realizar o trabalho. No entanto, podem
ocorrer tentativas de liderana, o que gera muitas vezes caos ou confuso entre os membros do time.

Expertise do Scrum Guidance Body

A Expertise do Scrum Guidance Body refere-se a regras documentadas e regulamentos, diretrizes de


desenvolvimento ou padres, e as melhores prticas.

Expertise do Time

A Expertise do Time refere-se ao conhecimento dos membros do Time Scrum e capacidade de entender as
Estrias de Usurio e as Tarefas do Backlog do Sprint, a fim de criar as entregas finais. A Expertise do
Time utilizada para avaliar as entradas necessrias para executar o trabalho planejado para o projeto.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 353


GLOSSRIO

ExplorerShopperVacationerPrisoner (ESVP)

Este um exerccio que pode ser realizado no incio da Reunio de Retrospectiva do Sprint para entender a
mentalidade dos participantes e definir a direo da reunio. Os participantes so convidados a indicar
anonimamente o que melhor representa sua viso na reunio.

Fase de Formao

A Fase de Formao a primeira etapa de formao do time, muitas vezes considerada uma fase divertida,
porque tudo novo e o time ainda no encontrou nenhuma dificuldade com o projeto.

Fase de Implementar

A Fase de Implementar inclui processos relacionados com a execuo das tarefas e atividades, para criar o
produto de um projeto.

Fase de Incio

Esta fase composta pelos processos relacionados ao incio de um projeto: Criar a Viso do Projeto,
Identificar o Scrum Master e o(s) Stakeholder(s), Formar o Time Scrum, Desenvolver os picos, Criar o
Backlog Priorizado do Produto, e Conduzir o Planejamento da Release.

Fase de Planejamento e Estimativa

A fase de Planejamento e Estimativa consiste em processos relacionados ao planejamento e estimativa de


tarefas, que incluem Criar a Estria de Usurio; Aprovar, Estimar e Comprometer as Estria de Usurio;
Criar as Tarefas; Estimatimar as Tarefas; e Criar o Backlog do Sprint.

Ferramentas de Rastreamento do Sprint

As Ferramentas de Rastreamento do Sprint so usadas para controlar o andamento de um Sprint, e saber o


que falta para o Time Scrum completar as tarefas do Backlog do Sprint. Uma variedade de ferramentas
podem ser usadas para monitorar o trabalho em um Sprint, mas uma das mais comuns o Scrumboard,
tambm conhecido como quadro de tarefas ou grfico de progresso.

Ferramentas de Software Automatizadas

As Ferramentas de Software Automatizadas so ferramentas usadas para o agendamento, coleta de


informaes, e distribuio.

354 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Fist of Five

O Fist of Five um mecanismo simples e rpido para chegar a um consenso em grupo e para conduzir uma
discusso. Aps a discusso inicial sobre uma determinada proposta ou deciso pendente, usando os seus
dedos, os membros do Time Scrum so convidados a votar em uma escala de 1 5.

Formar o Time Scrum

Os membros do Time Scrum so identificados durante esse processo. Normalmente, o Dono do Produto
tem a responsabilidade de selecionar os membros do time, mas muitas vezes o faz em colaborao com o
Scrum Master.

Fornecedor

Os Fornecedores incluem indivduos externos ou organizaes que fornecem produtos e servios que no
esto dentro das competncias essenciais da organizao do projeto.

Funo de Utilidade

A Funo de Utilidade um modelo usado para medir a preferncia ou a atitude do stakeholder em relao
ao risco. Definindo o nvel ou vontade do(s) Stakeholder(s) em aceitar o risco.

Garantia de Qualidade

A garantia de qualidade refere-se avaliao de processos e normas que regem o gerenciamento da


qualidade em um projeto, para garantir que eles continuam a serem relevantes. As atividades de garantia
de qualidade so realizadas como parte do trabalho.

Gerenciamento de Conflitos

As Tcnicas de Gerenciamento de Conflitos so usadas pelos membros do time, para gerenciar os conflitos
que possam surgir durante um projeto Scrum. Fontes de conflitos, muitas vezes incluem: horrios,
prioridades, recursos, hierarquia de subordinao, problemas tcnicos, procedimentos, personalidades, e
custos.

Gerenciamento de Qualidade

O Gerenciamento de Qualidade em Scrum permite que os clientes tornem-se cientes de quaisquer


problemas no incio do projeto, e os ajuda a reconhecer se um projeto ir ser til para eles ou no. O
Gerenciamento de Qualidade em Scrum facilitado por meio de trs atividades inter-relacionadas:

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 355


GLOSSRIO

1. Planejamento de Qualidade
2. Controle de Qualidade
3. Garantia de Qualidade

Grfico Burndown do Sprint

O Grfico Burndown do Sprint um grfico que mostra a quantidade de trabalho restante durante o
desenvolvimento do Sprint.

Grfico de Risco Burndown

Um grfico que mostra a gravidade do risco cumulativo do projeto, ao longo do tempo. A probabilidade de
vrios riscos so traados uns em cima dos outros, para mostrar o risco cumulativo sobre o eixo y. A
identificao inicial, a avaliao dos riscos, e a criao do Grfico de Risco Burndown, so feitas no incio
do projeto.

Identificao de Riscos

A Identificao de riscos um passo importante no Gerenciamento de Risco, o que envolve o uso de vrias
tcnicas para identificar todos os riscos potenciais.

Impedimentos

Um impedimento qualquer entrave ou obstculo que reduza a produtividade do Time Scrum.

Inspeo

A Inspeo refere-se ao monitoramento requerido para seguir o controle de processos empricos, para
garantir que as entregas do projeto estejam em conformidade com os requisitos.

Itens de Ao Atribuda e Datas de Vencimento

Uma vez que os Pontos de Melhoria Acordados tenham sido elaborados e refinados, os itens de ao para
implementar as melhorias podem ser considerados pelo Time Scrum. Cada item de ao ter uma data de
vencimento definida para a sua concluso.

Itens No Funcionais Propostos para o Backlog do Produto

Os Requisitos no-funcionais podem no ser totalmente definidos nas fases iniciais do projeto e podem
surgir durante as Reunies de Reviso do Sprint ou de Retrospectiva do Sprint. Esses itens devem ser
adicionados ao Backlog Priorizado do Produto assim que forem descobertos.

356 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Justificativa de Negcio

A Justificativa de negcio demonstra as razes para a realizao de um projeto. Ela responde pergunta:
"Por que este projeto necessrio?". A Justificativa de negcio direciona todas as tomadas de decises
referentes a um projeto.

Justificativa de Valor Contnuo

A Justivicativa de Valor Contnuo refere-se uma avaliao regular do valor de negcio, para determinar se
a justificativa ou a viabilidade de execuo do projeto, continuam a existir.

Justificativa do Projeto

A Justificativa do projeto inclui todos os fatores que implicam o projeto, sejam estes positivos ou negativos,
escolhidos ou no (por exemplo, a capacidade insuficiente para atender a demanda existente e prevista, a
diminuio da satisfao dos clientes, lucros baixos, a exigncia legal etc).

Lancha

A Lancha uma tcnica que pode ser usada para realizar a Reunio de Retrospectiva do Sprint. Os
membros do time desempenham o papel da tripulao de uma Lancha. O lancha deve chegar a uma ilha,
que simbolicamente a Viso do Projeto. Post-its so usados pelos participantes para indicar motores e
ncoras. Os motores so as coisas que os ajudam a chegar ilha, enquanto ncoras so as coisas que
esto impedindo-os de chegar ilha. Este exerccio time-boxed em alguns minutos.

Lies Aprendidas pelo Time Scrum

Espera-se que um Time Scrum auto-organizado e competente, aprenda com os erros cometidos durante o
Sprint, e que estas lies aprendidas ajudem os times a melhorar o seu desempenho em Sprints futuros.

Lder Assertivo

Os Lderes assertivos enfrentam problemas e demonstram confiana para estabelecerem autoridade com
respeito.

Lder Autocrtico

Os Lderes autocrticos tomam decises por conta prpria, permitindo aos membros do time pouco, ou
nenhum envolvimento na tomada de decises. Este estilo de liderana deve ser usado somente em raras
ocasies.

2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK) 357


GLOSSRIO

Lder de Apoio/ Treinamento

Os Lderes de apoio e treinamento emitem instrues e, em seguida, apoiam e monitoram os membros do


time atravs da escuta, ajudando, incentivando, e apresentando uma perspectiva positiva em momentos de
incerteza.

Lder de Direo

O Lder de Direo instrui os membros do time sobre as tarefas que so necessrias, quando e como elas
devem ser realizadas.

Lder Laissez Faire

Um estilo de liderana, onde grande parte do tempo o time deixado sem superviso, e o lder no interfere
nas atividades dirias de trabalho. Isso muitas vezes leva a um estado de anarquia.

Lder Orientador de Tarefa

Os Lderes Orientadores de Tarefas impem a concluso de tarefas e o cumprimento de prazos.

Lder Servidor

Os Lderes Servidores empregam a escuta, a empatia, o comprometimento e a introspeco, ao


compartilhar poder e autoridade com os membros do time. Os lderes servidores alcanam resultados,
focando as necessidades do time. Este estilo a personificao do papel do Scrum Master.

Lderes de Delegao

Os Lderes de Delegao esto envolvidos na maioria das tomadas de decises; no entanto, eles delegam
algumas responsabilidades de planejamento e tomada de deciso aos membros do time, especialmente se
estes membros so capazes de lidar com as tarefas. Este estilo de liderana apropriado em situaes em
que o lder est focado em detalhes especficos do projeto, e quando o seu tempo limitado.

Limite de Risco

Refere-se ao nvel em que o risco aceitvel para organizao do stakeholder. Um risco cair acima ou
abaixo do Limite de Risco. Se estiver abaixo, o stakeholder ou a organizao estaro mais propensos a
aceitar o risco.

358 2017 SCRUMstudy. Um Guia para o Conhecimento em Scrum (Guia SBOK)


GLOSSRIO

Lista de Tarefas

Essa uma lista abrangente, que contm todas as tarefas que o Time Scrum se comprometeu a realizar
durante o Sprint atual. Ela contm as descries de cada tarefa.

Lista de Tarefas de Esforo Estimado

A Lista de Tarefas de Esforo Estimado uma lista de tar