Não compreendi muito bem como requisitos não funcionais viram histórias. Eles poderiam ser chamados características dos sistemas. Ou seja, são itens que são os "valores" do produto a ser desenvolvido. Então devem ser atendidos no desenvolvimento das histórias. Não bastaria prioriza-los primeiro pois farão parte de (quase) todas as histórias. Um exemplo simplório: Um requisito não funcional diz que o sistema deve rodar em todos os dispositivos android. Então não adianta a equipe desenvolver uma tela de cadastro de clientes linda, mas que não roda em telefones com tela pequena. Nem adianta este requisito ser a primeira história do backlog. Como o Scrum lida com isto?
2
respostas
respostas
Requisitos não funcionais e priorização
Os requisitos não funcionais são tão importantes quanto os requisitos funcionais, por exemplo posso precisar que meu sistema seja otimizado e que as telas não demorem muito a carregar (RNF). Um bom momento para priorizar ele seria após o desenvolvimento da tela. Dessa forma trabalharia passo a passo, primeiro desenvolvo uma tela sem me preocupar com o RNF e depois de terminado penso no requisito. No caso que descreveu por exemplo, a idéia talvez fosse primeiro definir o escopo do trabalho, funcionar até android 2.2 por exemplo. Com isso já estaria limitado a utilizar apenas as funcionalidades que funcionam nessa versão. Mas pode ser que você queira que, numa versão mais atual de android, a tela seja a mais bonita possível. Nesse caso talvez faça sentido desenvolver do melhor modo possível primeiro e depois tenha a tarefa que pense na compatibilidade, assim o time gastaria um tempo no desenvolvimento e depois pensaria na melhor de atender o requisito citado.
Espero que tenha ajudado, se ficar confuso só perguntar novamente.
Olá Decio!
Sei que sua dúvida talvez já até não exista mais (dado o tempo da questão), mas permita-me contribuir com a discussão aqui no fórum.
No meu entendimento, um item de backlog é uma história do usuário.
Toda história do usuário possui as atividades (o que é/deve ser feito para implementar a história) e os testes de aceitação (os critérios que consideram a história done - DoD).
As histórias podem ser derivadas de um requisito funcional ou não funcional. Em geral, requisitos funcionais refletirão em tarefas das histórias e requisitos não-funcionais em critérios dos testes de aceitação.
Entretanto, podem haver histórias cujas tarefas tem exclusivamente o objetivo de atender requisitos não funcionais.
A figura 36 do livro Agile Think Canvas ajuda a entender esse relacionamento, dê uma olhada: https://books.google.com.br/books?id=4NMeDgAAQBAJ&pg=PA148&lpg=PA148#v=onepage&q&f=false
No exemplo que você deu, "rodar em todos dispositivos Android" pode ser um critério de aceitação da história "cadastro de clientes". Esta história só estará Done quando este critério for atingido.
Como o Márcio citou, pode ser que, lá na frente, depois de várias histórias entregues, uma nova versão do Android exija uma refatoração/reescrita do código. Então, pode-se adicionar ao backlog uma história com tarefas que especificamente focarão neste requisito não funcional. Ou seja, tanto as atividades quanto os critérios de aceitação estão baseados no requisito não funcional.
Espero ter contribuído.