Estimating a login feature
The story that gets estimated three times before someone says the word 'password reset'.
Login is never a 3. Someone will say 3.
The reason "add login" reads small is that everyone in the room has shipped login before, on a different product, with a different set of decisions already made. The scope you remember is the scope from last time — not the scope you're about to take on. The story sounds like a known quantity until someone asks one of the five questions below, and then it isn't.
The trap isn't that login is hard. It's that the discussion ends before the trade-offs are visible. Senior engineers anchor on "we have a library for this." PMs anchor on the happy-path screenshot. Whoever has actually built the thing recently is the one who breaks the consensus, usually with a question that wasn't on the ticket.
What gets said in the room
Backend: "It's just JWT, we have the library."
Security: "Password reset isn't 'just JWT'."
PM: "Do we need 2FA on day one, or is that a follow-up?"
Frontend: "Are we federating to Google and Apple, or rolling our own?"
SRE: "What's the rate limit on the login endpoint?"
Questions worth asking before voting
- Is there a password-reset flow, and who owns the email template?
- Federated identity — Google, Apple, SSO — or username/password only?
- Session storage: JWT, server session, both, refresh tokens?
- Rate limiting and account-lockout on the login endpoint?
- 2FA in scope now, or a deliberate "later"?
- Audit logging for failed attempts?
If your team votes 3 on login, the conversation hasn't happened yet. Send it back.
Adjacent: common mistakes covers what goes wrong inside the session; how to run a session has the four-phase loop. Or open a session and walk this story through it.