In developing accurate requirements and derive accurate estimates from client engagements, user stories are increasingly becoming the de facto standard for documenting.
Simple in concept, but difficult to master, user stories have this basic format:
As a <actor/user>, I can/want <what> so that <why>
The “how” is kept out, since that is what the delivery team should figure out. You shouldn’t need as a client know how the car was built as much as how to properly run and maintain it.
However, the trouble can be with getting the right level of granularity to the user stories so no “big surprises” come out weeks or months after the initial requirements gathering process. There is an art to recognize this and doesn’t follow any template or “silver bullet”. There are many ways to help define user stories and going to the appropriate level of detail should include recognizing asking questions even in the details for say highlighting key facts of a product. It can be done in one form of highlighting but upon further research, there can be multiple ways with a “wish list” or favorite, commonly chosen favorites by others with similiar tastes or similiar products.
That’s when the devil is in the details and has to be handled through many questions and sufficient planning.
Lean-Agile Enterprises 
I would shy away from trying to get accurate estimates and accurate requirements especially in complex system. I would focus on continuous feedback. The purpose of User Stories is to engage conversation.
LikeLike
Joshua,
Agreed on your insight. You are therefore aware of Ron Jeffries 3 C’s with Card, Conversion, Commitment and am referencing a summary of that idea for building well-formed User Stories: http://guide.agilealliance.org/guide/threecs.html.
At the same time, my point is that the team should always strive for accuracy in estimates, but not precision. For instance, a common process for a team to make estimates during a Sprint Planning session is to use planning poker. When doing planning poker, the team should be in agreement with their resulting estimates (or at least come to as close to one as the team is willing). Planning Poker uses the Fibonacci series (1,2,3,5,8,13, etc.) and using more accurate estimates like 6.85 would be too detailed with the information known at that time.
So always strive for accuracy with what is known now, but not precision. Inspect and adapt those estimates through continuous feedback as you recommend.
LikeLike
Hi Mike. I am glad you already understand the underlying values of User Stories. I have seen that this tool has been overly abused by development team that is why I shy away from talking about it these days.
LikeLike