How can conversations happening over a User Story be 'recorded' as agreed-to requirements?

during refinement activity, conversations happen around multiple aspects of a Story and it emerges as a well-defined, well-understood one. 

Shouldn't it emerge as one that is ready for a Sprint Planning commitment, sufficiently understood and estimated so negotiations for a Done implementation can continue?

we tend to jam our Stories with all those conversation-related details, which makes all our Stories quite bulky

if you are discussing the level of details at functional expectations during refinement, I believe you add that as Acceptance Criteria. Rather if you are discussing technical design steps also, then you are already covering 'How to do' topic(This is one of the topics during Sprint planning that developers can do without PO). 

However, if doing so helps team to better understand to commit in a sprint, they can continue. But remember, User stories are not contract notes, they should be 'Negotiable' at any point of time. So 'agreed-to-requirement' state can reduce agility.

My question is - is this a good way to have Stories on our Sprint Backlog or should we keep details only at the level of conversations (in that case, how do we ensure we don't forget about those details)?

@Soumyadeep Mishra, At the end of the day, the aesthetics of the user story don't matter. As long as there is a shared understanding amongst the Scrum Team members on what needs to be done and what outcome to achieve, the rest isn't that relevant.

What outcome do we need to achieve? and, How will we know we have achieved it? are two good questions to test whether the story is refined well enough. This may even be a good opportunity for the Scrum Team to directly interact with their stakeholders to get sufficient clarity.

I'm going with a standard answer to a lot of questions about making things better in Scrum.  

Have you asked the Developers this question?  After all, they are the ones that have to take the Product Backlog Item (in this case your User Story) and turn it into a valuable increment of the product.  Let them decide what is too much or too little information to capture.  At the same time, the Product Owner has to fully understand what is captured so that they can convey information to stakeholders.  

All of us can give you our opinion and suggest some practices that some of our teams have used, but for the real answer you need have the Scrum Team decide.

Now MY OPINION is that there should be a clear statement that explains the changes needed to the Product, why those changes are needed and how/who will benefit from the changes.  Having stated criteria that will enable everyone to know the work is done is useful but in some circumstances not needed. I do not subscribe to the "standard User Story format".  I use whatever language structure necessary to adequately convey the information.  For example, I've seen Product Backlog Items that had nothing but a screen shot with a notation.  

MY RECOMMENDATION is that you don't get caught up in making this a procedural thing.  Every situation is unique and they should be treated as such.  Do what is necessary but do not makes things necessary if they do not serve a purpose for the situation.  The Manifesto for agile software development has a principal that I believe is very undervalued.  It is the 3rd from the bottom, 10th from the top.  

Simplicity -- the art of maximizing the amount of work not done -- is essential. 

Shouldn't it emerge as one that is ready for a Sprint Planning commitment, sufficiently understood and estimated so negotiations for a Done implementation can continue?

Thanks for your response @Ian Mitchell! You're correct; it emerges as an item which is sufficiently understood by the team so that they can commit for it during the Sprint Planning. However, in order to get to that 'sufficiently understood' refined stage and to be able to commit to the Story, they tend to put all the knitty-gritty details around the 'What' & 'How' in the Story, although this process continues till the Sprint Planning uptill these items make their way into the current Sprint Backlog.

if you are discussing the level of details at functional expectations during refinement, I believe you add that as Acceptance Criteria

Thanks for your response @Balaji Dhamodaran! I completely agree with your above point. However, it doesn't seem correct when its stretched to the extreme and team puts all the functional details as acceptance criteria. Some points are understood and covered under the wider acceptance criteria buckets but I as a Scrum Master finds it very hard to convince my team members about the same.

The actual reason for team's current state of mind is that they have faced challenges in the past when the Client (my team works for an onshore client) came back on the requirements saying - it was not meant to be implemented like this. Although the PO should act as a customer-proxy for the team, there are other business stakeholders who, although are not part of the Scrum Team, have a bigger say in the delivered increment. Although team tries to demo them the increment/s during the Sprint Review session, its not practically feasible to show them every aspect of the working increment and that's where the dispute happens sometimes.

So, in order to avoid this situation to crop again, team jams their Stories with all sorts of details so that they become the 'agreed to' scope of work....

At the end of the day, the aesthetics of the user story don't matter. As long as there is a shared understanding amongst the Scrum Team members on what needs to be done and what outcome to achieve, the rest isn't that relevant.

Thanks for responding @Steve Matthew! Ideally, this is how it should be, as per your above words. However, what I have observed that its not enough for the team to have that shared understanding, even the other business stakeholders, who are not part of the Scrum team but sponsors the entire program/ delivery, should also have the same understanding.

The challenge here is that these stakeholders don't come to our Scrum events to discuss these requirements (not that they should necessarily come!), but later on, at some point of time, when we have already delivered the increment, come back saying this was not the agreed-to requirement. And to make it worse, team might not have included that aspect of the increment during their Sprint Review session to them (its not practically feasible to show them every aspect of the working increment  in a time-boxed Review session).

Have you asked the Developers this question?  After all, they are the ones that have to take the Product Backlog Item (in this case your User Story) and turn it into a valuable increment of the product.  Let them decide what is too much or too little information to capture.  At the same time, the Product Owner has to fully understand what is captured so that they can convey information to stakeholders.  

Thanks for responding @Daniel Wilhite! Its actually the developers themselves who demand every piece of information to be captured in the Stories. At the end of the day, our Stories look like Functional Requirement Specification documents (however thin slice of requirement it might represent).

The problem here is a lack of trust between the team and the business stakeholders (client). We're a comparatively new team and it has happened in the past that the stakeholders have come back saying that it was not meant to be implemented like this. Although the PO tries to convey the information to the stakeholders but its only that much he can do as its very difficult to get hold of them and explain about the captured information about the Stories.

I have tried multiple times to highlight this to the Client organization senior management but they tend to push it over to the Scrum Team saying that they misunderstand the requirements. Therefore, in order to shield themselves from this problem, team tends to create the Stories with all the knitty-gritty details (around the What and the How), so that they become part of the captured-information or agreed-to information which they can then refer back to, if questioned later on.

The by-product of this process is that we don't get enough time to come to the other sets of the Stories which would make up our Sprint Goal and they don't get sufficiently refined or understood.

Therefore, in order to shield themselves from this problem, team tends to create the Stories with all the knitty-gritty details (around the What and the How), so that they become part of the captured-information or agreed-to information which they can then refer back to, if questioned later on.

So the team is being very transparent with their interpretation of the Product Backlog Item and you feel that is a problem?  

You said that the team is new.  Trust does not happen immediately.  It has to be earned from both parties.  This very well could be an over reaction but it is working.  I had a team do something similar and it actually helped to build trust.  When the detailed documentation was captured and discussed, it helped the business and the Scrum Team start to understand how to communicate better.  They learned how each other thought and how some terms translated from business-speak to tech-speak.  Over time the considerable documentation started to diminish because the two entities started to trust that each was doing the best they can and that no one was intentionally doing harm.  There were still some missteps in what was produced but that is why you involve stakeholders in the process and get their feedback during the Sprints. 

A SUGGESTION is that as Scrum Master you should encourage conversations about the practice with your client and the Scrum Team.  Have them discuss the benefits they see to this approach.  Ask the client if they find it useful or if there would be any other ways that they feel would be better for them. Have the Developers explain to the client why they do this.  Look at the Scrum Values in the Scrum Guide.  Have the client and the Scrum Team read those values and discuss them. 

 “It’s just what I asked for, but not what I want” 

Sometimes we get this kind of reaction from clients.

Workshop kind of approach can be taken to minimise this differences. You could experiment with 'Behavioural Driven Development'(BDD). Try and see if it helps team and client.

Thanks @Daniel Wilhite, @Balaji Dhamodaran! Appreciate your help & explanation on this topic; definitely worth a try!