•What kind of criteria to use to decide when something should be done?

JBC- If the team is confused, then something should be done.

•What actions are possible: create one or more stories, and maybe (or maybe not) retitle the existing story as part of that? Are other options possible?

JBC- If a story is confusing, it is often to big. This is probably your number one issue. It is very common. See my suggestions below.

•Who should be doing that? The story owner?

JBC- The product owner and the team. Ideally this work should be done during Sprint Planning.

•How do you handle reallocation of points? Do you add more points to the new stories? Do you adjust the points on the original story?

JBC- I'm going to defer to better experts on scrum level implementation for this. My mentors have always cautioned against changing story points in the middle of a release. If you can break the story down into tasks, not full stories, then usually that is just the break down of the story and you don't story point the tasks (but many folks will man hour the tasks)

What kind of criteria to use to decide when something should be done?

If the team is confused, then something should be done.

What actions are possible: create one or more stories, and maybe (or maybe not) retitle the existing story as part of that? Are other options possible?

If a story is confusing, it is often to big. This is probably your number one issue. It is very common. See my suggestions below.

Who should be doing that? The story owner?

The product owner and the team. Ideally this work should be done during Sprint Planning.

How do you handle reallocation of points? Do you add more points to the new stories? Do you adjust the points on the original story?

I'm going to defer to better experts on scrum level implementation for this. My mentors have always cautioned against changing story points in the middle of a release. If you can break the story down into tasks, not full stories, then usually that is just the break down of the story and you don't story point the tasks (but many folks will man hour the tasks)

I'm not sure refactoring is the word you are looking for. Reading your description I would call it either "rewriting" or more likely "decompose" the story.

If a story is confusing, it is often to big.

Here are four steps I have learned for breaking down vague stories into concise stories.

Find the Conjunctions: This is the first stage to user story break down. Take an existing story and find all the conjoining phrases (and, for, or, so, but, either, both, after, before, until, etc.). At each conjunction, break the story. Flesh out the one before the conjunction and move on. You can end up with several new stories from just a single user story.

Generic Words: “The user Logs In” can be a very generic statement. If your product supports multiple OS types and even mobile devices, then each one of those is its own user story. Anytime there is ambiguity in a word “Large,” “Easy,” or something you can’t test for, then narrow down the ambiguity. Often this will result in conjunctions (As a user I want to log in from my iPhone, iPad, Android, Mac and PC) and then you can break them down into their own stories.

Reverse the Acceptance Criteria: One of the advantages of applying acceptance criteria on even the vaguest user story is you then have a basis to dive into more information. Exploring having a masseuse for your day spa could quickly lead to both new users – As a private person I want the masseuse to come to my room, as an active person I want the day spa close to the beach and other water sports – and new stories – Mobile masseuses, Satellite location by the beach.

The truly helpful result is when the acceptance test gives you even more detailed user stories. The “Facial Treatment” acceptance criteria can lead to user stories to cover mineral treatments, mud masks, acupressure massage and so on. Each of these becomes the foundation of a new user story.

Time Line: The last in the line, this technique is particularly useful if you haven’t done Story Mapping on the product. Time line looks at a user story from the perspective of it being done and the team is asked to envision how it would work when done. This creates a timeline of events. Each event can then be turned into a user story.

I'm not sure refactoring is the word you are looking for. Reading your description I would call it either "rewriting" or more likely "decompose" the story.

•What kind of criteria to use to decide when something should be done?

JBC- If the team is confused, then something should be done.

•What actions are possible: create one or more stories, and maybe (or maybe not) retitle the existing story as part of that? Are other options possible?

JBC- If a story is confusing, it is often to big. This is probably your number one issue. It is very common. See my suggestions below.

•Who should be doing that? The story owner?

JBC- The product owner and the team. Ideally this work should be done during Sprint Planning.

•How do you handle reallocation of points? Do you add more points to the new stories? Do you adjust the points on the original story?

JBC- I'm going to defer to better experts on scrum level implementation for this. My mentors have always cautioned against changing story points in the middle of a release. If you can break the story down into tasks, not full stories, then usually that is just the break down of the story and you don't story point the tasks (but many folks will man hour the tasks)

Here are four steps I have learned for breaking down vague stories into concise stories.

Find the Conjunctions: This is the first stage to user story break down. Take an existing story and find all the conjoining phrases (and, for, or, so, but, either, both, after, before, until, etc.). At each conjunction, break the story. Flesh out the one before the conjunction and move on. You can end up with several new stories from just a single user story.

Generic Words: “The user Logs In” can be a very generic statement. If your product supports multiple OS types and even mobile devices, then each one of those is its own user story. Anytime there is ambiguity in a word “Large,” “Easy,” or something you can’t test for, then narrow down the ambiguity. Often this will result in conjunctions (As a user I want to log in from my iPhone, iPad, Android, Mac and PC) and then you can break them down into their own stories.

Reverse the Acceptance Criteria: One of the advantages of applying acceptance criteria on even the vaguest user story is you then have a basis to dive into more information. Exploring having a masseuse for your day spa could quickly lead to both new users – As a private person I want the masseuse to come to my room, as an active person I want the day spa close to the beach and other water sports – and new stories – Mobile masseuses, Satellite location by the beach.

The truly helpful result is when the acceptance test gives you even more detailed user stories. The “Facial Treatment” acceptance criteria can lead to user stories to cover mineral treatments, mud masks, acupressure massage and so on. Each of these becomes the foundation of a new user story.

Time Line: The last in the line, this technique is particularly useful if you haven’t done Story Mapping on the product. Time line looks at a user story from the perspective of it being done and the team is asked to envision how it would work when done. This creates a timeline of events. Each event can then be turned into a user story.