A good story — user type or enabler type — is estimable.
In order for it to be implemented, the agile team must estimate how complex a story is and the amount of work required to complete it.
Rule of thumb for estimating — at a minimum — a story is this: can it be completed within a single iteration?
BTW… a rule of thumb for estimating— at a minimum — a feature is this: can it be completed within a single Program Increment?
Don’t worry about getting it wrong the first or two attempts in estimating. Team’s estimation ‘accuracy’ will increase over time and so will the team’s predictability.
Try this: present a story to your teammates. Ask them to provide an estimate. Use the aforementioned minimal estimation technique: can it be completed within a single iteration? If that yields a ‘yes’ answer, then ask the team to provide a point estimate — use the modified Fibonacci sequence.
If your team is unable to estimate a story then perhaps the story is too large or uncertain.
What to do?
Too large: split it into smaller stories
Uncertain: create a technical or functional spike. Spike is a ‘exploratory’ type of an enabler story. The spike story usually yields one or more estimable stories.
Estimating a story warrants a conversation… to draw out any hidden assumptions and missing acceptance criteria; and to clarify the team’s shared understanding of the story.
Therefore, the conversation surrounding the estimation process is as important as — or more important than — the estimate.