Estimativa de um recurso de login
Como estimar o escopo de um recurso de login: o escopo oculto — redefinição de senha, autenticação de duas etapas (2FA), federação, limitação de taxa, sessões — e as questões a serem esclarecidas antes que alguém vote.
As histórias do Login quase nunca recebem nota 3 — mas sempre tem alguém que dá nota 3.
“Adicionar login” parece algo simples porque todos na sala já lançaram um login antes, em um produto diferente, com um conjunto diferente de decisões já tomadas. O escopo de que você se lembra é o da última vez — não o escopo que você está prestes a assumir. A história parece algo já conhecido até que alguém faça uma das perguntas abaixo; a partir daí, ela deixa de ser.
O problema não é que o login seja difícil. E sim que a discussão termina antes que as vantagens e desvantagens fiquem visíveis. Os engenheiros de backend se apegam ao argumento de que “temos uma biblioteca para isso”. Os gerentes de produto se apegam à captura de tela do cenário ideal. Quem realmente desenvolveu o produto recentemente é quem quebra esse falso consenso, geralmente com uma pergunta que não constava no ticket.
O que se fala na sala
Backend: “É só JWT, já temos a biblioteca.”
Segurança: “A redefinição de senha não é ‘apenas um JWT’.”
PM: “Precisamos da autenticação de dois fatores (2FA) logo no início, ou isso é algo para se fazer posteriormente?”
Front-end: “Vamos nos associar ao Google e à Apple ou desenvolver nossa própria solução?”
SRE: “Qual é o limite de taxa do endpoint de login?”
Perguntas que vale a pena fazer antes de votar
- Existe um fluxo para redefinição de senha? E quem é o responsável pelo modelo de e-mail?
- Identidade federada — Google, Apple, SSO — ou apenas nome de usuário e senha?
- Armazenamento de sessão: JWT, sessão do servidor, ambos, tokens de atualização?
- Limitação de taxa e bloqueio de conta no endpoint de login?
- A autenticação de dois fatores (2FA) já está incluída no escopo ou foi deliberadamente deixada para “mais tarde”?
- Registro de auditoria para tentativas malsucedidas?
A maioria dessas respostas é “trivial” ou “isso é assunto para outro ticket”. Conte as respostas do segundo tipo. Se houver duas ou mais, você ainda não tem uma história — você tem um candidato para dividir, e o 3 em que você estava prestes a votar está avaliando a coisa errada.
Se sua equipe votar “3” ao fazer login, a conversa ainda não aconteceu. Reenvie a mensagem.
Veja também: erros comuns no Planning Poker aborda o que pode dar errado durante a sessão; como conduzir uma sessão apresenta o ciclo de quatro fases. Confira os outros exemplos práticos de estimativa, ou inicie uma sessão gratuita de Planning Poker e analise essa história passo a passo.