User Stories - How detailed it should be ?

During the initial days of requirement gathering session, the product owners end up writing the epics. These epics needs to be broken further down into the user stories .   One common question repeatedly asked by the novice product owners is when is the right time to stop splitting the user stories ?   

If you Google around there are many articles written about this topic. 

Some of the options proposed by various authors include:

1.  Stop detailing when you feel the user story is big enough to be implemented in 3 – 4 days

2. Stop detailing when you feel the user story can be implemented in one iteration

3. Quite commonly referred acronym is the “INVEST” model.  More details about this model can be found here,   
    
I really like the INVEST model however,  if the Product Owners(PO) and developers are new to Agile, the above model will not help them much. I still feel that it looks pretty abstract to them.  

In one of the real world case studies, a group of “new to Agile”  product owners and developers  applying the INVEST model on user stories got into a debate for couple of days. They were not willing to budge with their own understanding of  “What testable” means, as each of them had their own explanation.  

So, just telling some one to follow the INVEST model may not be sufficient.

I have my own opinion about this,  while I am coaching the Agile teams, I recommend an iterative approach to detail out the user stories. Each time the user story is created, I ask the product owners to apply the INVEST principle to begin with and then share it with the development team to check their confidence level . If they are able to understand it easily and say that they can code this story, then probably it is the right size.   If not,  then the user stories needs to be split or detailed out further.  The developers take the important seat here. The developers need to review it because, they are the people on the ground implementing the same.

If the team is working in distributed model with POs  and developers distributed across the globe, then the POs could write the user story on Wiki or JIRA kind of tool . The developers on the other end can write their comments/questions as part of the feedback loop.