Olá Pessoal,
Mais um post, da série Agile e veremos como escrever boas user stories. Este é um ponto importante, pois uma boa user story deve ser entendida tanto pelo team técnico quanto pelo cliente/PO.
Lets…
Sabemos que escrever as user stories, é “trabalho” do PO, mas em teoria, porque na prática quem vai escrever ou é o ScrumMaster ou o time. Nem sempre dá para seguir o que temos na literatura de acordo com a realidade do mercado. Mas o objetivo deste post não é esse e sim tentar responder: “as use stories do seu projeto são boas?” Ou seja, para seu cliente, ela é valiosa? Ele olha para ela e sabe de fato o que significa que será feito?
Lendo o livro JR The samurai Agile (o qual em breve vou publicar um review), em um dos seus capítulos ele aborda sobre o assunto e vi que já cometi alguns erros quando precisei escrever algumas user stories alguns meses atrás em um projeto pessoal. Um dos problemas foi não ter percebido o quanto estava técnico alguns pontos na user story. E o JR fez uma pergunta interessante: “Se seu cliente estivesse com fome e apenas as duas opções abaixo ele teria para escolher, o que é mais claro para ele? “
1. Estória: Ernie’s Tech Diner
- C++ 3 days
- Connection pooling 2 days
- Model-View_presenter pattern 5 days
2.Estória: Sam’s Business Pancake House
- Create user account 3 days
- Notify subscribers of new listings 2 days
- Cancel subscription 1 day
Com certeza a estória dois faz mais sentido para o negócio do cliente. Os termos são simples e fáceis de serem entendidos. E o mais comum: quando somos muito técnico é escrever como na primeira estória e SM deve ficar atento com isso caso todo o time esteja participando da escrita das US. E em outro exemplo o JR trouxe que podemos ser técnicos e o cliente entender. A estória abaixo não perde seu valor:
Add database connection pooling: é dificil para o cliente entender
Mas…
Reduce page load time from 10 secs to 2 secs.
Parece que faz mais sentido para o cliente e você já sabe o que acontece nos bastidores para atingir o objetivo da user story (US).
Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.
- Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
- Negociável: é que ela pode ser alterada e adaptada e não fechada.
- Testável: que seja possível criar testes que valide aquela história. Algo como:
Login with expired:
Testable:
– redireciona logins expirados
– mostra mensagens de erros apropriadas
- Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.
Vou ficando por aqui, espero que tenham gostado do post.
See ya!