One of my major complaints about creating “user stories” is that the discipline of writing “User Stories” has diminished and they become written so that only the person creating the story actually knows what is expected. In many organizations, anyone can write a user story. I have no problem with that as long as the person entering it has been coached and the discipline of writing them is maintained.
As a …
I want …
So I can …
With this alone you can at least get to some sort of relative estimation. Instill this discipline in the organization and you’ll see, if you’re capturing metrics, a reduction in time to get the story prioritized. But the real win, and I’m not sure how to quantify this, is that the teams will experience less confusion by having a fairly good idea of what is expected and they’ll certainly be able to relatively estimate it in less time.
Optionally, and this takes even more coaching and organizational discipline, write the beginning of the acceptance criteria as well.
Given …
When …
Then …
It’s a starting point at least and that’s what user stories are supposed to be, a starting point, a place to begin the discussion of what is needed, by whom, and by when. User Stories are meant to facilitate a discussion between the team, they were never meant to be handed off to the team as complete requirements.