User Stories - Writing down the Conversation Results

Yes, documenting the details after the team discusses and gains a shared understanding is perfectly a valid approach; it helps with recall and audit requirements (traceability). What's really important is for the team to focus on having those healthy conversations first rather than writing down the requirements and passing them on.

Please be cautious - don't write too much details in a user story otherwise it will become a requirement doc.

A User Story is not a reminder OF a conversation, it is a reminder to HAVE that conversation.

The people who are involved in creating the product should be part of that conversation. The point is to gain a shared understanding of what should be built. Preferably, the conversation should be held as shortly as possible before the actual building of it so that the details are still fresh in everyone's mind and the story is still valid.

That said, when discussing the story, do write down notes, add pictures, take photos of any whiteboard drawings, add wireframes, designs, examples, spreadsheets with calculations, etc. Whatever it takes to get to that shared understanding of the story between everyone involved in creating it.

User stories are based on CCC
Card, Conversation, Confirmation

The team is focus on the user, the user story has to be short to "fill" a post-it.
The user story is shared and known by the team --> this is the conversation part. When the US is about to be developed, it is more accurate, and the need is more detailed.
The confirmation is the way to check if the need is well implemented.

As you may know, US are not mandatory by scrum (just like scrum board). It could be considered as a good practice.
http://enfocussolutions.com/the-three-c-s-of-user-stories/

Some articles of Mike Cohn ore maybe bob galen explain a side effect of US --> writing technical user stories is not easy (how to speak as a user when you want to change your DB schema?).
Just think about it

Much of the conversation could should be concentrated into acceptance criteria which will become your acceptance tests and really high level requirements. I also see many organizations blowing off the value of a user story, or the so that part of it. If the story does not have value why do it. If you can't measure value at a user story or higher value again why do it. I know it is not as easy as it sounds especially if your organizational culture is not there yet and that's a big reason for failure in agility today. I also like to get team members involved with capturing important pieces of the conversation with a collaborative tool electronic or not. I don't think a facilitator like a PO or SM can capture all the thoughts going on, translate and facilitate and xxx.

User stories are a technique, not the only way. Limiting the Scrum Team to not recording enough information or barring them from addressing technical concerns that will affect productivity, testability, and performance which is doing everyone involved (including customers) a disservice. The idea of acceptance criteria works well for both demonstrable feature stories and technical work; they are in essence a brief requirements document. Agile values "Working software over comprehensive documentation" which does not preclude a Scrum Team from such brief record keeping activities.

I would expect that discussing the requirements results in changes in the acceptance criteria. You will probably add some acceptance criteria en might even change some of the existing acceptance criteria into new ones that might be smarter/easier/doable.

In that scenario you should update the story's acceptance criteria.

Also any other decisions made during the refinement should be "logged", so that you can refer to it later. Just be careful not t odocument too much.

Hi Benjamin,

out of the three "C"s only the first and last should be documented. You can not document the whole conversation unless you voice-record it (not very useful later anyway). The result of Conversation should be Confirmation, which is the documentation of what will be presented to the PO at the Review meeting. All the background and clarifications are less important at the end.

Hope this helps,
Michael

On this topic, when is the appropriate time for the conversation? I was told that the team sees the story for first time in grooming session. It is in business terms, they then size it to some sort of points with no discussion of what solution will be implemented. The once the sprint starts the team discusses the design for first time

As sprints on average are getting shorter and shorter and stories are getting split into smaller and smaller chunks I think the line of when to do design is blurring. My teams are now getting into design in refinement meetings or in plain old collaboration because the pace is fast and the stories are small. That is not the answer for everyone. I think it depends on many variables but I would start with what Scrum recommends but if it doesn't work don't wait to experiment.

With points its also important that the points are relative, you are comparing stories to other stories. Not going to get into all the logistics of how you get there from nothing but RELATIVE sizing is important. Also remember points are really only used for few things. To forecast how much work/stories to take on in an increment and in that vain to determine velocity which with along with capacity and other inputs determines the forecast. The points may also be used by the PO and team in more strategic planning dare I say release or project planning:)