Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Throughout a good agile project, you should expect to have user stories written by each team member.

Also, note that who writes a user story is far less important than who is involved in the discussions of it.

As new information is learned, the team must negotiate with the Product Owner regardless of what it is. If the Developers feel strongly about something they think something needs adjusting, they are responsible for communicating the changes to the Product Owner before acting.

Empiricism in Scrum is an approach whereby the team continuously learns and improves from mistakes. In Scrum, empiricism means that the team makes decisions and changes based on what the customer is experiencing, rather than what the developers intended them to experience. Additionally, the empiricism meaning in Scrum is the concept that customer feedback directly impacts the team’s actions.

Product Backlog refinement is an ongoing process in which the Product Owner and the Development Team collaborate on reviewing and revising detail, estimates, and orders for items in the Product Backlog.

The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. The Product Owner isn’t part of the Development Team and can invest as much time as necessary and enlist the help of other members of the Scrum Team.

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that everyone on the Scrum Team understands well the goal, scope, and product domain;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility;
• Facilitating Scrum events as requested or needed.

Kanban and Scrum are project management methodologies that complete project tasks in small increments and emphasize continuous improvement. But the processes they use to achieve those ends are different. While Kanban is centered around visualizing tasks and continuous flow, Scrum is more about implementing timelines for each delivery cycle and assigning set roles.

Methodology comparison between Kanban and Scrum:

1. Roles: Kanban has no defined roles. Scrum has a Scrum master, Product Owner, and Development Team.
2. Delivery cycle: Kanban is continuous. In Scrum, the Sprint cycle lasts one to four weeks.
3. Change policy: For Kanban, changes can be incorporated at any time. In Scrum, changes are generally not made during the sprint.
4. Artifacts: Kanban uses a Kanban board. Scum has Product backlog, sprint backlog, and product increments.
5. Tools: Kanban uses Jira Software, Kanbanize, SwiftKanban, Trello, Asana. Scrum uses Jira Software, Axosoft, VivifyScrum, and Targetprocess.
6. Key concepts or pillars: Kanban is about Effectiveness, efficiency, and predictability. Scrum is about Transparency, Adaptation, and Inspection.