Estimating an SSO integration
How to estimate an SSO integration: the work lives outside your codebase, in the identity provider's quirks. The questions to answer before you vote a number.
SSO is mostly someone else’s quirks — spike the identity provider first; the rest is plumbing.
“Add SSO” reads like one feature. It’s two. The first is a small piece of OAuth or SAML or OIDC plumbing — well-documented, libraries exist, every modern auth library has a tutorial. The second is everything the identity provider does that isn’t in the tutorial: the claim names that don’t match the spec, the redirect-URI rules that are stricter than the spec, the session timeout that doesn’t match yours, the off-by-one in how groups get serialised, the metadata endpoint that returns invalid XML on Tuesdays. The first part is the story everyone can vote on. The second part is the points.
Which means the estimate isn’t really about SSO. It’s about this identity provider, and whether anyone on the team has integrated against it before. Okta with a vanilla SAML config is a different story from Azure AD with a custom claims rule that nobody on either side fully understands. A team that ships an Okta integration in a sprint will spend three sprints on a federated AD FS deployment with a custom proxy in front of it — and the code they write looks almost identical at the end.
What gets said in the room
Backend: “It’s an OAuth flow. Library handles it. 5 points.”
Security: “Which IdP? Okta? Azure AD? Custom SAML?”
Backend: “…does it matter?”
Security: “Yes. Their claims aren’t the spec’s claims.”
Lead: “Has anyone on this team integrated with their IdP before?”
SRE: “What’s the rollback if it breaks for half our users?”
The lead’s question is the one that decides the estimate. If someone has shipped against this provider, the story is small and well-bounded. If nobody has, the story is two unknown-shaped pieces of work — and the right move isn’t to estimate harder; it’s to time-box a spike against the provider’s actual behaviour and size the implementation after.
Questions worth asking before voting
- Which identity provider, specifically? Okta, Azure AD, Google Workspace, Auth0, custom?
- Has anyone on the team integrated against this provider before?
- OAuth, SAML, or OIDC — and which version of each?
- What’s the user-provisioning model — JIT, SCIM, manual?
- Group-to-role mapping: do we need it? Where does the mapping live?
- What happens to existing local accounts during cutover?
- Session timeout, idle timeout, MFA enforcement — whose policy wins?
- Can we test against the customer’s actual provider, or only a sandbox?
If two or more of these come back as “that’s its own ticket,” the story is too big: split out provisioning, role mapping, and migration as their own stories and size the auth flow on its own.
Don’t vote a number until you know whose identity provider you’re integrating against. The provider is the story.
See estimating a third-party API swap for the related “someone else’s quirks” pattern, and the other worked estimation examples for more. Open a free planning poker session once the spike has answered which provider and which quirks.