Diferente dos metódos tradicionais, o Scrum leva em conta que os humanos tomam as decisões baseados nas informações que possuem à mão e portanto o processo decisório deveria ser distribuído pela duração do projeto permitindo mudanças rápidas quando novas informações são obtidas.

Assim, ao invés de um conjunto de requerimentos escritos antes do desenvolvimento, o Scrum se baseia em histórias que nada mais são que lembretes para uma comunicação entre o dono do produto e o time que vai desenvolvê-la.

O detalhamento de uma história deve ser postergado até que haja um melhor entendimento do que se quer e para que se quer aquela funcionalidade.

Quando o dono do produto for escrever uma história para seu time, ele deve ter em mente as seguintes características de uma boa história:

Independente
Histórias que possuem dependências com outras histórias causam problemas de priorização, planejamento e estimativa de tamanho. Essas dependências podem ser evitadas combinando-as em uma história maior mas independente ou procurando uma forma diferente de dividir histórias.

Negociável
As histórias não devem ser contratos que obrigam sua implementação. Elas são lembretes sobre uma conversação que deve ocorrer em algum momento entre o dono do produto e o time e portanto não devem incluir muitos detalhes além daqueles já conhecidos ou sobre os quais alguma decisão já foi tomada.

Valiosa para usuários e clientes
As histórias deveriam ser escritas pelos usuários e/ou clientes (os compradores do software) pois, assim, refletiriam seus desejos e necessidades. Quando uma história é escrita de forma técnica ou com uma linguagem que só o time entende, o usuário terá dificuldade de medir seu valor e priorizar adequadamente

Estimável
O time deve conseguir estimar o tamanho de uma história. Quando o time não tem conhecimento sobre o domínio da história, ou sobre as tecnologias envolvidas, ou se ela é muito grande, a estimativa torna-se muito difícil. Um conversa com os usuários que conhecem o assunto da história e o uso do spike (investigação sobre as tecnologias e soluções possíveis) para que o time faça uma estimativa mais embasada.

Pequena
As histórias não devem ser nem muito grandes nem muito pequenas. Épicos (histórias grandes) são dificeis para priorizar e planejar. Elas devem ser divididas. Normalmente são de dois tipos: histórias compostas e histórias complexas. O Épico composto é a união de várias histórias menores. Nesse caso há várias maneiras de dividi-la. No caso de Épicos complexos a divisão é mais difícil e normalmente deve-se dividir em duas, uma para investigação e outra para desenvolver a funcionalidade. No caso de histórias muito pequenas (quando estimar o tamanho leva mais tempo que fazê-la), como por exemplo, defeitos (bugs), elas devem ser agrupadas em uma história maior.

Testável
Somente se a história pode ser testada é que o time saberá que a terminou. Os requerimentos não funcionais não são testáveis, como uma história que pede que o software seja amigável. No entanto, as funcionalidades podem ser descritas de forma que o time possa desenvolver testes automatizados ou verificados manualmente.