Olá, pessoal!

Mais um artigo da série Agile! 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 na teoria, porque na prática quem vai escrever ou é o Scrum Master ou o time. Nem sempre a realidade do mercado consegue seguir o que temos na literatura. Mas o objetivo deste artigo não é esse e sim tentar responder: “as user 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?

Estou lendo o livro The Samurai Agile, de Jonathan Rasmusson (em breve vou publicar um review sobre ele); em um dos seus capítulos ele aborda sobre o assunto e vi que já cometi alguns erros quando precisei escrever user stories há um tempo, em um projeto pessoal. Um dos problemas foi não ter percebido o quanto alguns pontos na user story estavam técnicos.  O autor faz uma pergunta interessante: “Se seu cliente estivesse com fome e ele tivesse que escolher apenas entre as duas opções abaixo, o que seria mais claro para ele?”

1. História: Ernie’s Tech Diner

C++     3 days

Connection pooling     2 days

Model-View_presenter pattern           5 days

2. Histó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 histó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écnicos e escrevemos como na primeira história, o SM deve ficar atento com isso caso todo o time esteja participando da escrita das US. E em outro exemplo o autor trouxe que podemos ser técnicos e o cliente entender. A histó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.

See ya!