Muitas pessoas na TI acham que o método ágil significa desprezar toda a técnica e a documentação.

Na verdade o que a metodologia propõe é um constante exercício de valor, priorização com requisitos: o importante é o que deve ser feito primeiro para retornar o valor agregado para o cliente. Se o que retorna mais valor para o cliente é o requisito com maior incerteza, devemos começar a construí-lo primeiro, para rapidamente ajudarmos o cliente a materializar a ideia da sua necessidade. Ao mesmo tempo teremos o conforto necessário para continuar a construção do software.

Com isso, temos dentro do horizonte de uma sprint um produto funcionando, ou parte dele, e uma materialização dos requisitos, dadas as restrições de prazos e recursos. Para a próxima sprint as alterações sempre são bem-vindas. Os requisitos são sempre revistos, são aprimorados quando necessários e o feedback é sempre bem vindo, utilizado para construir um melhor produto. Dessa forma, o SCRUM aproveita o aprendizado durante o projeto.

O Scrum trata dos requisitos de software através do Product Backlog e Sprint Backlog. Deve-se deixar bem claro que o método Scrum não possui definido em sua implantação um Gerenciamento de Requisitos, como acontece com o RUP, os requisitos são apenas identificados, tratados e tornam-se funcionalidades do sistema em desenvolvimento. Mas são todos documentados.

As histórias (User Stories), artefatos que caracterizam algumas das metodologias ágeis, nesse caso o Scrum, são responsáveis por coletar os requisitos através do cliente, ou seja, é o próprio cliente quem cria as histórias. Depois elas são analisadas e tornam-se funcionalidades que são atribuídas ao Product Backlog, onde são analisadas e posteriormente ao Sprint Backlog para o início de uma Sprint.