O documento discute o produto backlog, que é uma lista dinâmica de funcionalidades desejáveis para o sistema que ainda não estão implementadas, mantida e priorizada pelo product owner. Ele também discute user stories como uma forma de descrever funcionalidades de forma concisa e centrada no usuário para promover discussão. Finalmente, discute a importância de refinar os requisitos progressivamente em vez de tentar documentar tudo antecipadamente.

2.  O produt backlog é uma lista de todas as
funcionalidades desejáveis num Sistema, que
não se encontram ainda em Produtivo.
 Deve ser mantido pelo product owner , de
acordo com uma ordem de prioridades.
 É muito dinâmico : são
adicionados, apagados e reprioritizados
items em cada sprint.

3. Detalhado de As user stories com prioridade mais elevada têm que
forma ser suficientemente claras para poderem ser
apropriada desenvolvidas na sprint seguinte. As user stories que
serão feitas mais tarde deverão ser descritas com
menos detalhes.
Estimado O product backlog é uma lista de todo o trabalho que
terá que ser feito, constituindo assim uma ferramenta
de planeamento útil.
Emergente Muda ao longo do tempo. À medida que se vai
(Actualizado) sabendo mais sobre o produto que se pretende, vão-
se adicionando, eliminando e reprioritizando user
stories.
Prioritizado Deve ser ordenado por ordem de importância dos
items. Trabalhando sempre de acordo com as
prioridades definidas, a equipa pode maximizar o
valor do produto ou do sistema que está a ser
desenvolvido.

4.  Os documentos escritos podem
◦ limitar o sentido crítico
◦ e diminuir a responsabilidade da equipa como um
todo;
Assim, devem-se equilibrar duas necessidades:
 a de documentar um projecto para a
posteridade,
 a da conversa e discussão que potencia o
enriquecimento do projecto.

5.  As user stories constituem a melhor forma de
mudar o enfoque daquilo que está escrito sobre as
funcionalidades, para a conversa sobre as
funcionalidades.

Umauser story é umauma descrição simples e curta
Uma user story é descrição simples e curta de uma
funcionalidade, vista da perspectiva da pessoa que necessita
de mesma, normalmente um utilizador ou um cliente do
da uma funcionalidade, vista da perspectiva da
Sistema.
pessoa que necessita da mesma, normalmente
um utilizador ou um cliente do Sistema.

6. O formato de uma user story é o
seguinte :
Como um<tipo de utilizador>,
eu pretendo<o objectivo> ,
de forma a que <razão invocada>.

7.  As user stories podem ser escritas em
cartões de 3”x5” .
 Um cartão contendo uma user story
funciona como uma promessa de dois
sentidos:
◦ Os membros da equipa prometem que falarão
com o product owner antes de começarem a
trabalhar na história;
◦ O product owner promete que estará disponível
quando a equipa estiver pronta para falar.

8.  A elaboração de casos de uso constitui um
método alternativo para expressar as
funcionalidades de um Sistema.
 Devem ser utilizados casos de uso breves,
poque as equipas de scrum funcionam
melhor com unidades de trabalho que sejam
mais curtas e concisas que o caso de uso
típico.

9.  Há sempre requisitos supervenientes –
funcionalidades ou características que não
era possível identificar com antecedência.
 Numa equipa de scrum, estes requisitos são
recebidos com naturalidade, aceitando-se
que não se consegue pensar em tudo, ao
mesmo tempo.

10.  O iceberg do Product Backlog
Princípio:
 Manter as tarefas mais curtas, no topo.

11.  Uma equipa deve “tomar conta” do seu
Product Backlog.
 Cerca de 10% do esforço de cada sprint deve
ser gasto na preparação do Product Backlog
para as próximas sprints.

12. Vantagens de refinar progressivamente os
requisitos:
 Não há uma necessidade real de saber todos
os detalhes de algo que não vai ser feito já…
 Porque, as coisas vão mudar…
 E o tempo para começar a apresentar
resultados, não é muito !

13.  Épicos são user stories grandes, que levam
mais do que uma ou duas sprints para serem
desenvolvidas.
 Um épico deve ser dividido em user stories
menores, porque uma equipa deve poder
terminar uma user story durante uma só
sprint.
 Alguns épicos são tão grandes que se
dividem ainda em épicos.

14. Como um utilizador, eu posso credenciar-me
Épico: com o meu login e password
de forma a que que possa confiar no Sistema.
Como um
utilizador, deve
ser-me pedida
credenciação
Como um novo utilizador, eu quero registar-
para aceder ao me utilizando login e password
Sistema, de forma a que o Sistema possa guardar a
de forma a que a minha infomação pessoal.
informação que
me diz
respeito, seja Como um utilizador registado, eu posso
vista apenas por alterar a minha password
mim. de forma a torná-la mais segura ou mais
fácil de recordar.

15. Como um utilizador registado, eu quero que o
Épico: Sistema me avise se a minha password é fácil
de adivinhar de forma a que
Como um seja fácil aceder à minha conta.
utilizador, deve
ser-me pedida
credenciação Como um utilizador esquecido, eu quero
para aceder ao poder pedir uma nova password de forma que
Sistema, eu não fique permanentemente bloqueado se
de forma a que a esquecer a password actual.
informação que
me diz
respeito, seja Como um utilizador registado, eu serei
notificado se ocorrerem três tentativas falhadas
vista apenas por de acesso à minha conta, de forma a que eu
mim. saiba se alguém tentou aceder à minha conta.

16. Podemos refinar requisitos, adicionando
condições de satisfação a uma user
story. Uma condição de satisfação
corresponde a um teste de aceitação de
alto nível, que, deverá ser bem sucedido
quando a user story estiver completa.

17. Assegurar que funciona com os dias mais
significativos para vendas:
Como vice Natal, Páscoa, dia de Ano Novo, dia do Pai
presidente da área e dia da Mãe.
de marketing,
quero poder
seleccionar certas
épocas de férias, Suportar féria que abranjam
quando fizer a
dois anos de calendário.
revisão de
performance das
acções publicitárias
da empresa, de
forma a identificar Seleccionar um período entre dois
as mais lucrativas feriados significativos, como o
tempo que medeia entre o dia de
Acção de Graças e o dia de Natal.

18. Numa equipa scrum os programadores e os técnicos
encarregados dos testes trabalham em conjunto.
Um tester deve fazer parte das discussões.
Por outro lado, aqueles que beneficiam da
documentação devem ser os que a produzem.
Assim, os testers tornam-se responsáveis pela
produção e manutenção das especificações
detalhadas, em termos de cenários testáveis, no
início de cada iteração.
.

20. Succeding with Agile from Mike Cohn
Tradução e adaptação:
Maria João Costa
Mjoao.gehl.costa@gmail.com