Série Agile:Como escrever boas user stories?

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!

Série Agile: Diferença entre User stories e Documentos de Especificações

 

olá Pessoal,

Neste post vou trazer o que ganhamos ao escrever User Stories ao invés de ter que gastar mais tempo escrevendo documentações de requisitos. Não estou dizendo que não devemos documentar, pelo contrário. Porém ,a idéia é saber o que e como documentar.

Lets go..

User Stories promove os seguintes pontos:

– Aprendizado;

– Traz precisão;

– Encoraja a comunicação face-to-face com o cliente;

– Possibilita feedback em tempo real;

– Evita a falsa sensação de que temos tudo documentado correto e só falta implementar;

– Permite uma colaboração e inovação com o time.

Documentos de requisitos

– São grandes e cansativos;

– Encoraja o trabalho por imaginação com falsos ‘achismos’;

– É difícil de planejar;

– Feedback em tempo real é inexistente;

– Desencoraja abertura de colaboração e invocação com o time

Isso quer dizer que não vou documentar? Não. Em projeto Agile há documentação sim, porém ela não é o meio primário de obter as coisas e nossa última fonte de obter o entendimento, conversar com o cliente, é mais importante.A diferença é que aqui evitamos o desperdício do tempo documentando, pois ao terminar toda documentação, o que foi escrito no inicio talvez não tenha mais valor para o cliente.

Vou ficando por aqui, espero que tenham gostado do post.

abraços, see ya!!