User Story - thoughts, feedback

Why would a participant want this and what would they use the information for?

It is missing the "so that" in the end. Not that it is important. As long as the Development Team members know what needs to be built and tested and the Product Owner knows the purpose, it should be good enough. Personally, I don't like to waste time and effort on business process. I want to focus on the product and its value.

If it allows a useful conversation, it's a decent start.

I would hope members of the Scrum Team asks questions for the important things that are unclear to them.

That will depend on context, but could be things like:

• Does the participant want to see their own time, or that of someone/something else in a different timezone?
• Does the format of the time matter?
• How accurate does this time need to be? (What are the consequences if it is wrong?)
• Do we need to be sure the participant has seen the correct time before we allow them to vote?

To be honest, I do not really like this as a user story. It proposes a solution to an unknown problem. This means that the development team does not know why they are building it and it might not be the best solution for the problem.

I would suggest to add  a description of the issue that the participant is having and maybe even wat the result is, like Ian said.

To be honest, I do not really like this as a user story. It proposes a solution to an unknown problem. This means that the development team does not know why they are building it and it might not be the best solution for the problem.

On the plus side, a user story is a placeholder for a conversation about a potential requirement, which is happening at least on this forum. As long as the relevant Development Team are also engaged in a similar conversation, then the story may prove fit for purpose.

While it does start a conversation as @Ian Mitchell points out, that conversation should be occurring with the Development Team and not here.  Not trying to be offensive but @Katharina Kluge, you have posted a lot of user stories for us to discuss on the forum. It might be better if you would post questions on what issues you are having with understanding how to write better user stories so that we can offer suggestions in that regard. Taking a jump forward I'll give some advice that I have found helpful and others have to. 

An User Story is not required by Scrum and is a practice taken from Extreme Programming.  In Scrum, a Product Backlog Item is something that contains information about a problem or opportunity that is needed for a product.  The Scrum Guide states 

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

User stories are one way to do this as they usually follow the format of 

As <who> <when> <where>, I <want> because <why>

Notice that the "test descriptions that will prove its completeness when 'Done'" is missing.  Those come in the form of Acceptance Criteria.   

However, also notice as I pointed out earlier that the User Story format is not mentioned in the Scrum Guide.  You can state all of the needed information in any form that you want as long as it is well understood by the Scrum Team and especially the Development Team.  The key parts, that you as a Product Owner, should provide are the description, value and order.  In this context, value is not story points. It is the actual value that these changes will bring to the end user/stakeholders when delivered. 

In the example you provided this time

As a participant, I want to see date and timezone display with correct time on the submit button before selecting my vote.

I see a description but there is nothing to indicate the value of deliverying a time stamp to the participant. You state it needs to be on the submit button but the Development Team may be able to provide a solution to the problem that better supports the value it brings if they knew the value.  

I will also say that your specifying the placement of the time would be better presented in the Acceptance Criteria.  I will only include technical details such as that if they are absolutely required in order to provide the value.  For example, if there is some kind of regulation that requires it to be embedded in the button then it would be included in the problem statement. 

@Simon Mayer brought up good points about the time formatting and designation. Another aspect of one of his questions "How accurate does it need to be?" leads to whether the time displayed is a timestamp or running time? For example, if there was a deadline of Midnight July 31st to have your vote submitted and the time is shown as a timestamp of when you loaded the page, it is possible that a participant could load the page at 11:55 pm July 30, walk to the kitchen to get a glass of water before reading the poll, then submit the poll at 12:01 am July 31 but the timestamp still shows 11:55 pm July 30 on the button.  If we do not know the value of the timestamp, we could implement it incorrectly.  And if this is the actual use case you are solving for, then the "who" of the story would not be the participant, it would be the pollster because they want to make sure the participant is properly informed of when the submission is being provided. 

When wriitng user stories I find that "who" the hardest to determine.  It isn't always the person seeing the information or having to enter the information that is the beneficiary of the story.  Often it is the requestor that benefits from the story and it should be called out as such.